From sip-admin@lists.bell-labs.com Wed Nov 1 04:20: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 EAA23577 for ; Wed, 1 Nov 2000 04:20:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6CB2944338; Wed, 1 Nov 2000 03:20:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 60DE744337 for ; Wed, 1 Nov 2000 03:19:19 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V797LL65; Wed, 1 Nov 2000 10:15:03 +0100 From: "Hisham Khartabil" To: "Jean-Francois Mule" , Cc: Subject: RE: [SIP] SIP proxies and CSeq numbers 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 In-Reply-To: <6374EFC78443D41197DD00508B5C35DD0184509A@rwcxch02.clarent.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 1 Nov 2000 11:20:34 +0200 Content-Transfer-Encoding: 7bit I don't think this is a correct behaviour of the proxy. The proxy should wait for the ACK and then the new INVITE. It forwards the second INVITE with Cseq=2. If the proxy was confident that the authentication is ok, why would it challenge the client in the first place? Regards, Hisham Hotsip Finland -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jean-Francois Mule Sent: Tuesday, 31 October 2000 7:39 PM To: archow@hss.hns.com Cc: 'sip@lists.bell-labs.com ' Subject: RE: [SIP] SIP proxies and CSeq numbers (A record-route will be added in the call flow to close this discussion on the sip t.38 side). But I still believe we have a bug based on what you correctly outlined Arjun. CSeq numbers are truly relevant in the context of a sip transaction and can easily get out of sequence (sick), especially for statefull proxies. Unless the record-route header is added, we have a recipe for guaranteeing call failures. Take this other scenario where the proxy is seating between a public net & a private trusted net and the proxy requires authentication on one leg only. A -> P: authentication is required, A is in the public net. A initiates an invite (F1), P challenges A (F2) but P also sends the request to B (F3) while waiting for the credentials (proxies may act like this: the proxy knows that A comes from a known but untrusted network and has confidence the authentication should be ok so it sends the request F3 before receiving F4). Another justification for proxies to act this way may be that to check the credentials on F4, the proxy has check with a remote authentication server. P -> B: no authentication required If the UA A behaves as you stated in this scenario and sends the ACK directly to B, the CSeq=2 in the ACK: game over. Any suggestions on how do we fix this? Jean-Francois Mule' SIP UA: A Proxy SIP UA: B | | | | F1 INVITE (Cseq=1) | | |------------------------->| | | | | | F2 407 Proxy auth. req| | |<-------------------------| F3 INVITE (Cseq=1) | | |------------------------->| | F4 INVITE (Cseq=2) | | |------------------------->| | | | F5 Trying (Cseq=1) | | |<-------------------------| | F6 Trying (Cseq=2) | | |<-------------------------| | | | F7 200 OK (Cseq=1) | | |<-------------------------| | F8 200 OK (Cseq=2) | | |<-------------------------| | | | | F9 ACK (Cseq=2) ! | |---------------------------------------------------->| | | | > -----Original Message----- > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Monday, October 30, 2000 10:06 PM > To: Jean-Francois Mule > Cc: archow@hss.hns.com; 'sip@lists.bell-labs.com ' > Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax > cal ls - Internet Draft) > > > > > Jean, > Consider this situation: > > A sends an INVITE which goes through your Proxy to B. B sends > a 200 OK with > Contact as userb@here.com. > This is routed through your proxy and goes to A. > Now since A has a direct path to B (and the proxy did not do a > Record-Route), > A now sends the next request (ACK) directly to B ( protocol behaviour) > > The ACK must have the same CSeq as the INVITE although is a > transaction of > its own. But in this case, > the ACK will have the CSeq of A - P which is different from > the CSeq space > of P-B. Since ACK went directly > B would think this ACK is not valid. > The same problems will arise in any future requests within > the same call > which is forwarded directly. > > This , as you would notice induces incorrect behaviour. > > jean> PS: As for the Record-Route, it was omitted (while it > is key to proxy > jean> functions, isn't it optional after all? -- 6.34.1). > I'll add the > jean> Record-route to the next I-D revision - thanks. > > Yes, its not mandatory. However in your scenario, if you do not do > Record-Route > future request can skip your proxy who then cannot change > CSeq (if thats > needed in > the first place) > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 1 05:27: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 FAA22296 for ; Wed, 1 Nov 2000 05:27:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D31B344338; Wed, 1 Nov 2000 04:27:06 -0500 (EST) 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 057C044337 for ; Wed, 1 Nov 2000 04:26:56 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Nov 2000 10:26:51 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA08100; Wed, 1 Nov 2000 11:25:04 +0100 (BST) Message-ID: <39FFEF80.745BCF3D@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: Hisham Khartabil Cc: Jean-Francois Mule , archow@hss.hns.com, sip@lists.bell-labs.com Subject: Re: [SIP] SIP proxies and CSeq numbers 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, 01 Nov 2000 10:25:04 +0000 Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > > I don't think this is a correct behaviour of the proxy. The proxy should > wait for the ACK and then the new INVITE. It forwards the second INVITE > with Cseq=2. If the proxy was confident that the authentication is ok, why > would it challenge the client in the first place? It certainly isn't correct behaviour. Proxy 1 must not proxy on an INVITE (F3) after sending back a final response 407 (F2). It also must not change CSeq values in 200 responses (F7 + F8). Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > > Regards, > Hisham > Hotsip Finland > > -----Original Message----- > From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On > Behalf Of Jean-Francois Mule > Sent: Tuesday, 31 October 2000 7:39 PM > To: archow@hss.hns.com > Cc: 'sip@lists.bell-labs.com ' > Subject: RE: [SIP] SIP proxies and CSeq numbers > > (A record-route will be added in the call flow to close this discussion on > the sip t.38 side). > > But I still believe we have a bug based on what you correctly outlined > Arjun. CSeq numbers are truly relevant in the context of a sip transaction > and can easily get out of sequence (sick), especially for statefull proxies. > Unless the record-route header is added, we have a recipe for guaranteeing > call failures. > > Take this other scenario where the proxy is seating between a public net & a > private trusted net and the proxy requires authentication on one leg only. > A -> P: authentication is required, A is in the public net. A > initiates an invite (F1), P challenges A (F2) but P also sends the request > to B (F3) while waiting for the credentials (proxies may act like this: the > proxy knows that A comes from a known but untrusted network and has > confidence the authentication should be ok so it sends the request F3 before > receiving F4). Another justification for proxies to act this way may be > that to check the credentials on F4, the proxy has check with a remote > authentication server. > P -> B: no authentication required > > If the UA A behaves as you stated in this scenario and sends the ACK > directly to B, the CSeq=2 in the ACK: game over. > Any suggestions on how do we fix this? > > Jean-Francois Mule' > > SIP UA: A Proxy SIP UA: B > > | | | > | F1 INVITE (Cseq=1) | | > |------------------------->| | > | | | > | F2 407 Proxy auth. req| | > |<-------------------------| F3 INVITE (Cseq=1) | > | |------------------------->| > | F4 INVITE (Cseq=2) | | > |------------------------->| | > | | F5 Trying (Cseq=1) | > | |<-------------------------| > | F6 Trying (Cseq=2) | | > |<-------------------------| | > | | F7 200 OK (Cseq=1) | > | |<-------------------------| > | F8 200 OK (Cseq=2) | | > |<-------------------------| | > | | > | F9 ACK (Cseq=2) ! | > |---------------------------------------------------->| > | | | _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From extest-admin@lists.bell-labs.com Wed Nov 1 06:13: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 GAA11182 for ; Wed, 1 Nov 2000 06:13:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F86E44754 for ; Wed, 1 Nov 2000 05:07:54 -0500 (EST) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: sip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20001101100754.9F86E44754@lists.bell-labs.com> Date: Wed, 1 Nov 2000 05:07:54 -0500 (EST) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, sip-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for sip-archive@lists.ietf.org: List Password // URL ---- -------- sip@lists.bell-labs.com TDGd http://lists.bell-labs.com/mailman/options/sip/sip-archive%40lists.ietf.org From sip-admin@lists.bell-labs.com Wed Nov 1 06:53:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24382 for ; Wed, 1 Nov 2000 06:53:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01B1844339; Wed, 1 Nov 2000 05:53:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 6949F44337 for ; Wed, 1 Nov 2000 05:52:15 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA1BqUC26800; Wed, 1 Nov 2000 17:22:32 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525698A.00418298 ; Wed, 1 Nov 2000 17:25:32 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jean-Francois Mule Cc: archow@hss.hns.com, "'sip@lists.bell-labs.com '" Message-ID: <6525698A.00418249.00@sampark.hss.hns.com> Subject: RE: [SIP] SIP proxies and CSeq numbers 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, 1 Nov 2000 17:25:31 +0530 Jean, responses inline and prefixed by ARC> Take this other scenario where the proxy is seating between a public net & a private trusted net and the proxy requires authentication on one leg only. A -> P: authentication is required, A is in the public net. A initiates an invite (F1), P challenges A (F2) but P also sends the request to B (F3) while waiting for the credentials (proxies may act like this: the proxy knows that A comes from a known but untrusted network and has confidence the authentication should be ok so it sends the request F3 before receiving F4). Another justification for proxies to act this way may be that to check the credentials on F4, the proxy has check with a remote authentication server. P -> B: no authentication required If the UA A behaves as you stated in this scenario and sends the ACK directly to B, the CSeq=2 in the ACK: game over. Any suggestions on how do we fix this? ARC> Yes. The proxy should not forward the request (F3) to B in the first place. ARC> Since you say the proxy wants to challenge A, it should not go about forwarding ARC> the request to B. Let it wait for the challenge to be met. When agreed upon ARC> it should then forward the correct messge to B (in your case F4). Jean-Francois Mule' SIP UA: A Proxy SIP UA: B | | | | F1 INVITE (Cseq=1) | | |------------------------->| | | | | | F2 407 Proxy auth. req| | |<-------------------------| F3 INVITE (Cseq=1) | | |------------------------->| | F4 INVITE (Cseq=2) | | |------------------------->| | | | F5 Trying (Cseq=1) | | |<-------------------------| | F6 Trying (Cseq=2) | | |<-------------------------| | | | F7 200 OK (Cseq=1) | | |<-------------------------| | F8 200 OK (Cseq=2) | | |<-------------------------| | | | | F9 ACK (Cseq=2) ! | |---------------------------------------------------->| | | | > -----Original Message----- > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Monday, October 30, 2000 10:06 PM > To: Jean-Francois Mule > Cc: archow@hss.hns.com; 'sip@lists.bell-labs.com ' > Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 1 07:12:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01166 for ; Wed, 1 Nov 2000 07:12:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB32644339; Wed, 1 Nov 2000 06:12:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id A0B8944337 for ; Wed, 1 Nov 2000 06:11:17 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA1CBcC27453; Wed, 1 Nov 2000 17:41:39 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525698A.00434390 ; Wed, 1 Nov 2000 17:44:42 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Robert Sparks" Cc: "Jonathan Rosenberg" , airoy@hss.hns.com, sip@lists.bell-labs.com Message-ID: <6525698A.004342C2.00@sampark.hss.hns.com> Subject: RE: referred-by syntax (was RE: [SIP] (no subject)) 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, 1 Nov 2000 17:44:39 +0530 Robert, if you have the new ordering/syntax done already, would you mind posting them right away so we could plough in the correct version right away ? Thanks Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Robert Sparks" on 10/31/2000 11:11:29 PM To: "Jonathan Rosenberg" , Ashok I Roy/HSSBLR, sip@lists.bell-labs.com cc: Subject: RE: referred-by syntax (was RE: [SIP] (no subject)) nod - we agreed to that (and altering the syntax to remove the ordering dependency between "scheme" and "ref") in an earlier thread. I plan to get -02 out (which reflects that suggestion) this week. RjS > > URL parameters are _definitely_ allowed. If your URL has a > > semicolon in it, > > it is required to be bracketed with <>, so you don't have the > > ambiguity you > > suspected. > > I agree thats what you should do, but thats not what the grammar says. The > grammar says these are just URLs. To allow for the brackets, they > need to be > name-addr or addr-spec. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 1 07:29:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06655 for ; Wed, 1 Nov 2000 07:29:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ADA7444343; Wed, 1 Nov 2000 06:29:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 90E8244339 for ; Wed, 1 Nov 2000 06:28:24 -0500 (EST) Received: from dial-barska22.warman.com.pl ([195.164.232.23]:1044 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Wed, 1 Nov 2000 13:27:59 +0100 Message-ID: <3A000C0C.BF2CE4E3@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP discussion list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Errors handling on session description in ACK Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 01 Nov 2000 13:26:52 +0100 Content-Transfer-Encoding: 7bit Hello, When UAC send session description in INVITE request, UAS send 200 OK if it supports them or 606 Not Acceptable if not. Clear. (I assume ideal situation: no 1xx, etc.) When UAC doesn't send session description in INVITE (what means that it's going to do that in ACK), UAS' 200 OK contains description. Next, UAC sees that it will not be able to support capabilities of UAS. Does it send session descr. as if it would send in INVITE, regardless of this failed handshake ? This scenario will fail, because there is no way of negotiation after UAC has sent ACK, since ACK doesn't generate response. More generaly: 1. When UAC has an error and doesn't send session descr. in ACK ( INVITE did NOT contain session descr. as well), Should UAS just ignore such ACK and treat it as *not received* ? 2. Should garbage in body of type application/sdp generate 4xx response (which one ?) or 606 with appropriate code in Warning header (which one ?) By the way, I've compared bis-02 with draft-ietf-mmusic-sip-new-00.ps (August '99). Section 10.5.1 Unreliable Transport Protocols (bis-02): "(...)Response retransmissions cease when (...) the response has been RETRANSMITTED seven times." Section 10.5.1 (draft-ietf-mmusic-sip-new-00.ps): "(...)Response retransmissions cease when (...) the response has been TRANSMITTED seven times." Is it Typo or it must have been realy changed ? If it's only typo, bis-02' the section should be like in old draft or: "(...)Response retransmissions cease when (...) the response has been RETRANSMITTED SIX times." Comment? Best regards, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 1 12:07: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 MAA24995 for ; Wed, 1 Nov 2000 12:07:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 190BB44339; Wed, 1 Nov 2000 11:07:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id DF71A44337 for ; Wed, 1 Nov 2000 11:06:23 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA29519 for ; Wed, 1 Nov 2000 12:06:17 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA20472 for ; Wed, 1 Nov 2000 12:06:17 -0500 (EST) Received: from m14961-pc.mitre.org (128.29.105.115) by mailhub2.mitre.org with SMTP id 4920820; Wed, 01 Nov 2000 12:06:15 -0500 Message-ID: <3A004CE8.522AD4C1@mitre.org> From: Duncan Thomson Reply-To: duncant@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] What is the status of SAP? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 01 Nov 2000 12:03:36 -0500 Content-Transfer-Encoding: 7bit RFC 2543 (SIP) references the session announcement protocol (SAP), which exists only as a 1996 Internet Draft, that is, a "work in progress". So is SAP actually a "work in progress"? If so, why hasn't anything been published on it since the 1996 Internet Draft? Or is it considered obsolete? Thanks for any info, and apologies in advance if this is a dumb question. Duncan Thomson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 1 13:22:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18269 for ; Wed, 1 Nov 2000 13:22:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFAD344339; Wed, 1 Nov 2000 12:22:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id 45B8544337 for ; Wed, 1 Nov 2000 12:21:06 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3F394X>; Wed, 1 Nov 2000 10:18:39 -0800 Message-ID: <6374EFC78443D41197DD00508B5C35DD01845632@rwcxch02.clarent.com> From: Jean-Francois Mule To: archow@hss.hns.com Cc: "'sip@lists.bell-labs.com '" Subject: RE: [SIP] SIP proxies and CSeq numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 1 Nov 2000 10:18:38 -0800 Arjun: Your suggestion would be the recommended way of handling this scenario and this is how most of us are doing it. But in any case, I do not think we can enforce this at all. Again, my proxy may want to buy some time when sending F3 so that as soon as get F5, I have the F5 right in the queue and send the F6 right away. Jean-Francois. > ARC> Yes. The proxy should not forward the request (F3) to B > in the first > place. > ARC> Since you say the proxy wants to challenge A, it should > not go about > forwarding > ARC> the request to B. Let it wait for the challenge to be > met. When agreed > upon > ARC> it should then forward the correct messge to B (in your case F4). > > > Jean-Francois Mule' > > SIP UA: A Proxy SIP UA: B > > | | | > | F1 INVITE (Cseq=1) | | > |------------------------->| | > | | | > | F2 407 Proxy auth. req| | > |<-------------------------| F3 INVITE (Cseq=1) | > | |------------------------->| > | F4 INVITE (Cseq=2) | | > |------------------------->| | > | | F5 Trying (Cseq=1) | > | |<-------------------------| > | F6 Trying (Cseq=2) | | > |<-------------------------| | > | | F7 200 OK (Cseq=1) | > | |<-------------------------| > | F8 200 OK (Cseq=2) | | > |<-------------------------| | > | | > | F9 ACK (Cseq=2) ! | > |---------------------------------------------------->| > | | | _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 1 17:38: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 RAA20241 for ; Wed, 1 Nov 2000 17:38:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F33644337; Wed, 1 Nov 2000 16:38:06 -0500 (EST) 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 3733844336 for ; Wed, 1 Nov 2000 16:37:26 -0500 (EST) Received: from (hither.rfdsoftware.com) [209.192.222.62] by nautilus.shore.net with esmtp (Exim) id 13r6VC-0000IO-00; Wed, 01 Nov 2000 17:37:02 -0500 Received: from cx991414-a.dialout.net (cx991414-d.crans1.ri.home.com [24.180.58.118]) by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id RAA17914; Wed, 1 Nov 2000 17:29:45 -0500 (EST) Message-Id: <5.0.0.25.2.20001101172101.031cd7d0@webhost.tactical-sw.com> X-Sender: dnyon@webhost.tactical-sw.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: James Rafferty , Jean-Francois Mule , ietf-fax@imc.org From: David Yon Subject: RE: [SIP] RE: Request for information on using T.30/T.37/T.38 wit h SIP/SDP/ RTP Cc: sip@lists.bell-labs.com, "'Glenn Parsons'" , "'Herman Silbiger'" In-Reply-To: <11740AB18BD4D111BE8F00A0C9B8044F0347F2F0@nhmail1.admin.bro oktrout.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 01 Nov 2000 17:37:13 -0500 The draft of T.38 Annex-D I've read is here (can anyone point me to a more up-to-date draft?): ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/February00/ Based on that reading, the setup procedure of TCP is inextricably bridged between two protocols: SDP and SIP. It says that SDP is used to declare that (a) TCP will be used, and (b) which port number to connect to. But the direction of the call determines the direction of the TCP connection (callee must connect to caller, and caller must accept this connection), as this is not declared in SDP. So now instead of having a complete description of the TCP behavior solely in the SDP packets, the context of the call must be known in order to correctly predict the behavior of the endpoints. The I-D listed below addresses this problem, such that the behavior of the endpoints is fully described by the SDP exchange. That said, T.38 Annex-D and the TCP/SDP I-D do not conflict in any major way. The I-D defines that if the "direction" attribute is omitted, both sides are to attempt to establish connections. If T.38 opts to set up the TCP connection based on call context in lieu of the "direction" attribute, that's probably not a huge discrepancy. Anyone disagree? What is notably missing from my copy if T.38 Annex-D is an example of a T.38 SIP exchange that specifies TCP. The question I have is, what does the receiver of the call put into its return SDP packet if it is agreeing to use TCP? Does it say "TCP"? If so, what port number does it specify? Presumably the sender knows to ignore this port number, yes? At 04:46 PM 11/1/00 -0500, James Rafferty wrote: >To all - > >The registration from ITU-T SG8 for IANA as related to SDP was related to >the >Approval last February of Annex D to T.38, which defines how to use SIP/SDP >with T.38 for facsimile session control. T.38 needs to support both UDP >and TCP modes of operation, hence the need for the SDP extension to support >TCP (Glenn Parsons of Nortel was the editor). > >So, the methods for using TCP within SDP for T.38 session control purposes >have been described in detail in the T.38 Annex D. > >So, I'd suggest that people who want to write ID's related to this, take a >look at what is in the T.38 Annex D (TIES users can read it as TD262rev2 in >the SG8 informal FTP area). There is also a small amendment to T.38 annex >D (see Com8-114) which will be reviewed at the SG16 meeting during the week >of Nov 13-17. > >I just checked on the ITU site and notice that T.38 Amendment 2 is not >published yet, so the TD262rev2 above is the only access to that text at the >moment. Hopefully, this will change soon. > >James > >* ----------------------------------- >James Rafferty >Senior Product Manager, IP Telephony >jraff@brooktrout.com > >Brooktrout Technology >410 First Avenue >Needham, MA 02494 USA >Phone: +1-781-433-9462 >Fax: 781-433-9268 >www.brooktrout.com >Your Hook into the New Network(SM) > > > -----Original Message----- > > From: David Yon [mailto:yon@dialout.net] > > Sent: Monday, October 30, 2000 3:54 PM > > To: Jean-Francois Mule; ietf-fax@imc.org > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] RE: Request for information on using T.30/T.37/T.38 > > with SIP/SDP/ RTP > > > > > > I know that the I-D specifically defers the discussion of > > media transport > > using TCP rather than UDPTL, but at the same time it also > > refers to a new > > token "TCP" to be registered with IANA for use in SDP. I am > > of the opinion > > that simply specifying "TCP" is insufficient to describe how > > TCP-based > > Media Transport is to be negotiated between two endpoints. > > > > I've submitted an Internet Draft for the MMUSIC group which > > will hopefully > > be available in the IETF I-D area soon, but for the moment it > > can be read here: > > >ftp://ftp.dialout.net/drafts/draft-ietf-mmusic-sdp-tcpmedia-00.txt > >So, in regards to the SIP/T.38 I-D, my only comment would be that it take >into account the I-D on SDP/TCP. Or at the very least, participate with >better defining the SDP/TCP I-D such that is meets the needs of SIP/T.38 >when using TCP for Media Transport. As such, any comments on the I-D above >would be greatly appreciated. > >Again, hopefully the draft will be in the IETF area soon, I don't know why >it is taking so long to work through the queue. > >At 02:26 PM 10/27/00 -0700, Jean-Francois Mule wrote: > >There is an Internet-Draft on SIP and T.38 fax calls at > >http://search.ietf.org/internet-drafts/draft-mule-sip-t38callflows-00.txt > >It deals with how to negotiate a t.38 fax calls using sip as a signaling > >protocol (including switch over from audio/rtp to data/t38), the SDP > >attributes that itu-t sg-8 has registered with IANA. Comments are > >appreciated on this Internet-Draft. > > > > > > >David Yon >Chief Technical Officer >Dialout.Net, Inc. >yon@dialout.net > > 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 Wed Nov 1 18:40:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03685 for ; Wed, 1 Nov 2000 18:40:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 10CB244337; Wed, 1 Nov 2000 17:40:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id CECD844336 for ; Wed, 1 Nov 2000 17:39:49 -0500 (EST) Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 15:43:39 -0800 Message-ID: From: Sandeep Sahai To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Sip- Message OPTION Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 1 Nov 2000 15:43:30 -0800 Hi, Can any one tell me what is the sip-message for OPTION look like. I was trying to find the same in the call flow diagram document , but I cannot see an example for an OPTION sip message. So, please let me an example of sip-message for OPTION. Thanks Sandeep Sahai Ph:- 408-571-3388 (O) 510-487-2121 (R) Journey of thousand miles starts with single step. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 1 19:48: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 TAA18762 for ; Wed, 1 Nov 2000 19:48:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7F9944337; Wed, 1 Nov 2000 18:48:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by lists.bell-labs.com (Postfix) with ESMTP id 309EC44336 for ; Wed, 1 Nov 2000 18:47:56 -0500 (EST) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id QAA12358 for ; Wed, 1 Nov 2000 16:47:50 -0800 (PST) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 02 Nov 2000 00:47:50 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 16:47:48 -0800 Message-ID: From: "Agarwal, Aseem" To: "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] Handling of unknown SIP methods and headers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 1 Nov 2000 16:47:36 -0800 Hi, Pardon me if this has already been discussed earlier, but can somebody verify the following behavior : 1. Unknown method Stateless Proxy : Forward transparently Trans - Stateful proxy: Forward if possible, else 405/501 Call - stateful proxy: Forward if possible, else 405/501 Standalone Registrar server:Return 405/501 Redirect server: Return 405/501 UAS: Return 405/501 The decision to send 405 or 501 is dependent upon whether the received message is recognized or not. If the method is recognized and supported but not allowed, 405 is the appropriate response, else 501 should be sent. 2. Unknown SIP header(s) Stateless Proxy : Forward transparently Trans - Stateful proxy: Ignore and if possible forward Call - stateful proxy: Ignore and if possible forward Standalone Registrar server:Ignore Redirect server: Ignore UAS: Ignore -regards, aseem _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 00:13:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21711 for ; Thu, 2 Nov 2000 00:13:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F42844337; Wed, 1 Nov 2000 23:13:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 0225344336 for ; Wed, 1 Nov 2000 23:12:15 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA255jC07221; Thu, 2 Nov 2000 10:35:47 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525698B.001C472D ; Thu, 2 Nov 2000 10:38:52 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Sandeep Sahai Cc: "'sip@lists.bell-labs.com'" Message-ID: <6525698B.001C4577.00@sampark.hss.hns.com> Subject: Re: [SIP] Sip- Message OPTION Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=JygTJOpFvQSO2POw4aQSzXxtz15DQHr36OhF6mMLN7NToAlJLmRH2wXL" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 2 Nov 2000 10:38:47 +0530 --0__=JygTJOpFvQSO2POw4aQSzXxtz15DQHr36OhF6mMLN7NToAlJLmRH2wXL Content-type: text/plain; charset=us-ascii Content-Disposition: inline Maybe the one in the bis-draft would be of help: A caller Alice can use an OPTIONS request to find out the capabilities of a potential callee Bob, with-out --0__=JygTJOpFvQSO2POw4aQSzXxtz15DQHr36OhF6mMLN7NToAlJLmRH2wXL Content-type: text/plain; charset=windows-1257 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =93ringing=94 the designated address. Bob returns a description indicat= ing that he is capable of receiving audio encodings PCM mu-law (RTP payload type 0), 1016 (payload type 1),= GSM (payload type 3), and SX7300/8000 (dynamic payload type 99), and video encodings H.261 (paylo= ad type 31) and H.263 (payload type 34). C->S: OPTIONS sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP cat.wonderland.com From: Alice To: Bob Call-ID: 6378@cat.wonderland.com CSeq: 1 OPTIONS Accept: application/sdp S->C: SIP/2.0 200 OK From: Alice To: Bob ;tag=3D376364382 Call-ID: 6378@cat.wonderland.com Content-Length: 81 Content-Type: application/sdp v=3D0 o=3Dalice 3149329138 3149329165 IN IP4 24.124.37.3 s=3DSecurity problems t=3D3149328650 0 c=3DIN IP4 24.124.37.3 m=3Daudio 0 RTP/AVP 0 1 3 99 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:1 1016/8000 a=3Drtpmap:3 GSM/8000 a=3Drtpmap:99 SX7300/8000 m=3Dvideo 0 RTP/AVP 31 34 a=3Drtpmap:31 H261/90000 a=3Drtpmap:34 H263/90000 Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Sandeep Sahai on 11/02/2000 05:13:30 AM To: "'sip@lists.bell-labs.com'" cc: Subject: [SIP] Sip- Message OPTION = --0__=JygTJOpFvQSO2POw4aQSzXxtz15DQHr36OhF6mMLN7NToAlJLmRH2wXL Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Can any one tell me what is the sip-message for OPTION look like. I was trying to find the same in the call flow diagram document , but I cannot see an example for an OPTION sip message. So, please let me an example of sip-message for OPTION. Thanks Sandeep Sahai Ph:- 408-571-3388 (O) 510-487-2121 (R) Journey of thousand miles starts with single step. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip --0__=JygTJOpFvQSO2POw4aQSzXxtz15DQHr36OhF6mMLN7NToAlJLmRH2wXL-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 00:41:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29619 for ; Thu, 2 Nov 2000 00:41:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 453D644337; Wed, 1 Nov 2000 23:41:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web10304.mail.yahoo.com (web10304.mail.yahoo.com [216.136.130.82]) by lists.bell-labs.com (Postfix) with SMTP id 3CDA644336 for ; Wed, 1 Nov 2000 23:40:44 -0500 (EST) Message-ID: <20001102054038.58594.qmail@web10304.mail.yahoo.com> Received: from [203.197.174.238] by web10304.mail.yahoo.com; Wed, 01 Nov 2000 21:40:38 PST From: james jack To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Discussion Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 1 Nov 2000 21:40:38 -0800 (PST) Dear All: I have one question to discuss. In order to detect loop, RFC2543bis02 page 81 says"A request has been looped if the server finds its own address in the Via header field and the hash computation over the fields enumerated in Section 6.46.6 yields the same value as the hash part of the ¡°branch¡± parameter in the Via entry containing the proxy server¡¯s address.", Page 59"In order to be able to both detect loops and associate responses with the corresponding request, the parameter SHOULD consist of two parts separable by the implementation. One part, used for loop detection (Section 12.3.1), MAY be computed as a cryptographic hash of the To, From, Call-ID header fields, the Request-URI of the request received (before translation) and the sequence number from the CSeq header field. The algorithm used to compute the hash is implementation-dependent, but MD5 [38], expressed in hexadecimal, is a reasonable choice.". According to my knowledge, it is necessary to detect the Via to find whether loop or not, why use these parameters to detect loop, Is the hash is easy to implement? Could anyone give me advice on this? Thanks a lot! Best regards! Yours: James __________________________________________________ Do You Yahoo!? From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 00:50:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02471 for ; Thu, 2 Nov 2000 00:50:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1907644346; Wed, 1 Nov 2000 23:50:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 67FC244337 for ; Wed, 1 Nov 2000 23:49:20 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA04407; Thu, 2 Nov 2000 00:51:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YJQ4>; Thu, 2 Nov 2000 00:45:02 -0500 Message-ID: From: Jonathan Rosenberg To: "'Jean-Francois Mule'" , archow@hss.hns.com Cc: "'sip@lists.bell-labs.com '" Subject: RE: [SIP] SIP proxies and CSeq numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 2 Nov 2000 00:44:58 -0500 > -----Original Message----- > From: Jean-Francois Mule [mailto:jfmule@clarent.com] > Sent: Wednesday, November 01, 2000 1:19 PM > To: archow@hss.hns.com > Cc: 'sip@lists.bell-labs.com ' > Subject: RE: [SIP] SIP proxies and CSeq numbers > > > Arjun: > Your suggestion would be the recommended way of handling this > scenario and > this is how most of us are doing it. But in any case, I do > not think we can > enforce this at all. Well, we can't enforce people building elements compliant to the spec. The behavior you are advocating is simply not compliant. It will not function correctly with anyone elses equipment. It will result in bizarre, incorrect behavior (things like the called party gets rung even though the credentials fail, resulting in a dangling half call at the called party). -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 Nov 2 00: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 AAA03056 for ; Thu, 2 Nov 2000 00:51:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3AFBB44346; Wed, 1 Nov 2000 23:51:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CD1EE4434D for ; Wed, 1 Nov 2000 23:50:22 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA04423; Thu, 2 Nov 2000 00:52:33 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YJQX>; Thu, 2 Nov 2000 00:46:06 -0500 Message-ID: From: Jonathan Rosenberg To: "'duncant@mitre.org'" , sip@lists.bell-labs.com Subject: RE: [SIP] What is the status of SAP? 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, 2 Nov 2000 00:46:02 -0500 It is now RFC2974. -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: Duncan Thomson [mailto:duncant@mitre.org] > Sent: Wednesday, November 01, 2000 12:04 PM > To: sip@lists.bell-labs.com > Subject: [SIP] What is the status of SAP? > > > RFC 2543 (SIP) references the session announcement protocol > (SAP), which exists only as a 1996 Internet Draft, that is, a > "work in progress". So is SAP actually a "work in progress"? > If so, why hasn't anything been published on it since the > 1996 Internet Draft? Or is it considered obsolete? > > Thanks for any info, and apologies in advance if this is a > dumb question. > > Duncan Thomson > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 2 00:57: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 AAA04783 for ; Thu, 2 Nov 2000 00:57:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DC4B744354; Wed, 1 Nov 2000 23:57:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6C0C444353 for ; Wed, 1 Nov 2000 23:56:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA04451; Thu, 2 Nov 2000 00:58:12 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YJQ9>; Thu, 2 Nov 2000 00:51:46 -0500 Message-ID: From: Jonathan Rosenberg To: "'james jack'" , SIP@lists.bell-labs.com Subject: RE: [SIP] Discussion MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 2 Nov 2000 00:51:44 -0500 > -----Original Message----- > From: james jack [mailto:sipjames@yahoo.com] > Sent: Friday, October 20, 2000 2:50 AM > To: SIP@lists.bell-labs.com > Subject: [SIP] Discussion > > > Hi,All: > I have one question to consult, the question is that > about the 481 Call Leg/Transaction Does Not Exist, on > RFC2543bis02, which says "This status is returned > under three conditions: The server received a BYE > request that does not match any existing call leg, the > server received a CANCEL request that does not match > any existing transaction or the server received an > INVITE with a To tag that does not match the local tag > value. (A server simply discards an ACK referring to > an unknown transaction.)" . I can't understand the > words "or the server received an INVITE with a To tag > that does not match the local tag value", could > someone give me some example? According to my known,To > tag is inserted by UAS or redirect server. which means > To tag is used in response, how can a INVITE request > with a To tag? Subsequent INVITE requests from the caller to called party for the same call leg carry that tag in the To field. The 481 is sent if a UAS receives a request with a tag in the To field that it did not previously insert. -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 Nov 2 01:10:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10548 for ; Thu, 2 Nov 2000 01:10:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3438844345; Thu, 2 Nov 2000 00:10:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id C4EAC44336 for ; Thu, 2 Nov 2000 00:09:20 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for SIP@lists.bell-labs.com; Thu, 2 Nov 2000 00:09:15 -0600 (CST) From: Billy Biggs To: "Agarwal, Aseem" Cc: Sip List Subject: Re: [SIP] Handling of unknown SIP methods and headers Message-ID: <20001102000915.C1402@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from aseem@trillium.com on Wed, Nov 01, 2000 at 04:47:36PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 2 Nov 2000 00:09:15 -0600 Agarwal, Aseem (aseem@trillium.com): > Pardon me if this has already been discussed earlier, but can > somebody verify the following behavior : You are almost correct. I think your table is slightly misleading. > 1. Unknown method > Trans - Stateful proxy: Forward if possible, else 405/501 > Call - stateful proxy: Forward if possible, else 405/501 A proxy should proxy the request. Only if the request is destined for the proxy (the Request-URI was 'sip:my.proxy.com') should the proxy return a 501. > Redirect server: Return 405/501 Again, if the request is destined for a user of the redirect server, the server should happily return a 300-class response to the unknown request. It should only return a 501 if the request was destined for the redirect server (the Request-URI was 'sip:my.redirect.com') and the server didn't understand it. > 2. Unknown SIP header(s) > Trans - Stateful proxy: Ignore and if possible forward > Call - stateful proxy: Ignore and if possible forward Why do you say 'if possible'? It would be very, very bad if a proxy stripped out headers it didn't understand. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 01:31:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23331 for ; Thu, 2 Nov 2000 01:31:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 43A1C44345; Thu, 2 Nov 2000 00:31:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id EEB3544337 for ; Thu, 2 Nov 2000 00:30:15 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 2 Nov 2000 00:16:42 -0600 (CST) From: Billy Biggs To: archow@hss.hns.com Cc: Sandeep Sahai , SIP List Subject: Re: [SIP] Sip- Message OPTION Message-ID: <20001102001642.D1402@div8.net> References: <6525698B.001C4577.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <6525698B.001C4577.00@sampark.hss.hns.com>; from archow@hss.hns.com on Thu, Nov 02, 2000 at 10:38:47AM +0530 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 2 Nov 2000 00:16:42 -0600 Note that this should be cleaned up. There is no Via or CSeq in the response, the CSeq in the request starts at 1, the From has no tag, and there is no Content-Length. > C->S: OPTIONS sip:bob@example.com SIP/2.0 > Via: SIP/2.0/UDP cat.wonderland.com > From: Alice > To: Bob > Call-ID: 6378@cat.wonderland.com > CSeq: 1 OPTIONS > Accept: application/sdp > > S->C: SIP/2.0 200 OK > From: Alice > To: Bob ;tag=376364382 > Call-ID: 6378@cat.wonderland.com > Content-Length: 81 > Content-Type: application/sdp > > v=0 > o=alice 3149329138 3149329165 IN IP4 24.124.37.3 > s=Security problems > t=3149328650 0 > c=IN IP4 24.124.37.3 > m=audio 0 RTP/AVP 0 1 3 99 > a=rtpmap:0 PCMU/8000 > a=rtpmap:1 1016/8000 > a=rtpmap:3 GSM/8000 > a=rtpmap:99 SX7300/8000 > m=video 0 RTP/AVP 31 34 > a=rtpmap:31 H261/90000 > a=rtpmap:34 H263/90000 -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 01:43:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01170 for ; Thu, 2 Nov 2000 01:43:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB12744345; Thu, 2 Nov 2000 00:43:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 6A78544345 for ; Thu, 2 Nov 2000 00:42:47 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA26a4C11767; Thu, 2 Nov 2000 12:06:05 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525698B.00248BA4 ; Thu, 2 Nov 2000 12:09:10 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Billy Biggs Cc: archow@hss.hns.com, Sandeep Sahai , SIP List Message-ID: <6525698B.00248A6A.00@sampark.hss.hns.com> Subject: Re: [SIP] Sip- Message OPTION Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 2 Nov 2000 12:09:06 +0530 Well, Its in the examples section and the intro text for Section 16 says: "In the following examples, we often omit the message body and the corresponding Content-Length and Content-Type headers for brevity." (BTW, responses has a C-Len). And I dont think the From needs a tag to be correct, does it ? Further, I dont see the problem of using CSeq 1. This OPTIONS message may well be sent from alice to bob even if they are not in a call. So 1 seems ok. So I guess only Via needs to be added, in this list. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Billy Biggs on 11/02/2000 11:46:42 AM To: archow cc: Sandeep Sahai , SIP List Subject: Re: [SIP] Sip- Message OPTION Note that this should be cleaned up. There is no Via or CSeq in the response, the CSeq in the request starts at 1, the From has no tag, and there is no Content-Length. > C->S: OPTIONS sip:bob@example.com SIP/2.0 > Via: SIP/2.0/UDP cat.wonderland.com > From: Alice > To: Bob > Call-ID: 6378@cat.wonderland.com > CSeq: 1 OPTIONS > Accept: application/sdp > > S->C: SIP/2.0 200 OK > From: Alice > To: Bob ;tag=376364382 > Call-ID: 6378@cat.wonderland.com > Content-Length: 81 > Content-Type: application/sdp > > v=0 > o=alice 3149329138 3149329165 IN IP4 24.124.37.3 > s=Security problems > t=3149328650 0 > c=IN IP4 24.124.37.3 > m=audio 0 RTP/AVP 0 1 3 99 > a=rtpmap:0 PCMU/8000 > a=rtpmap:1 1016/8000 > a=rtpmap:3 GSM/8000 > a=rtpmap:99 SX7300/8000 > m=video 0 RTP/AVP 31 34 > a=rtpmap:31 H261/90000 > a=rtpmap:34 H263/90000 -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 02:07: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 CAA20245 for ; Thu, 2 Nov 2000 02:07:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92A7D44345; Thu, 2 Nov 2000 01:07:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.parsec.co.za (mail.parsec.co.za [196.37.137.10]) by lists.bell-labs.com (Postfix) with SMTP id 76F6B44337 for ; Thu, 2 Nov 2000 01:06:34 -0500 (EST) Received: from thys (unverified [172.17.5.45]) by server00.parsec.co.za (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 02 Nov 2000 08:50:19 +0200 From: "Thys Nel" To: "'Billy Biggs'" , Cc: "'Sandeep Sahai'" , "'SIP List'" Subject: RE: [SIP] Sip- Message OPTION Message-ID: <014d01c04498$cea23ab0$2d0511ac@thys> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20001102001642.D1402@div8.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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, 2 Nov 2000 08:47:44 +0200 Content-Transfer-Encoding: 7bit Does anyone have examples of messages flows with OPTIONS processed by a registrar server? The only example in the RFC is between 2 user agents, but the RFC states that a registrar must also support it. I can't seem to find any description of when a registrar should respond to an OPTIONS request. Thys > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Billy Biggs > Sent: 02 November 2000 8:17 > To: archow@hss.hns.com > Cc: Sandeep Sahai; SIP List > Subject: Re: [SIP] Sip- Message OPTION > > > Note that this should be cleaned up. There is no Via or CSeq in the > response, the CSeq in the request starts at 1, the From has > no tag, and there > is no Content-Length. > > > C->S: OPTIONS sip:bob@example.com SIP/2.0 > > Via: SIP/2.0/UDP cat.wonderland.com > > From: Alice > > To: Bob > > Call-ID: 6378@cat.wonderland.com > > CSeq: 1 OPTIONS > > Accept: application/sdp > > > > S->C: SIP/2.0 200 OK > > From: Alice > > To: Bob ;tag=376364382 > > Call-ID: 6378@cat.wonderland.com > > Content-Length: 81 > > Content-Type: application/sdp > > > > v=0 > > o=alice 3149329138 3149329165 IN IP4 24.124.37.3 > > s=Security problems > > t=3149328650 0 > > c=IN IP4 24.124.37.3 > > m=audio 0 RTP/AVP 0 1 3 99 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:1 1016/8000 > > a=rtpmap:3 GSM/8000 > > a=rtpmap:99 SX7300/8000 > > m=video 0 RTP/AVP 31 34 > > a=rtpmap:31 H261/90000 > > a=rtpmap:34 H263/90000 > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 02:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09301 for ; Thu, 2 Nov 2000 02:55:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 27A2E44337; Thu, 2 Nov 2000 01:55:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id C629B44336 for ; Thu, 2 Nov 2000 01:54:22 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA27qWC13387; Thu, 2 Nov 2000 13:22:33 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525698B.002AE26D ; Thu, 2 Nov 2000 13:18:23 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: james jack Cc: SIP@lists.bell-labs.com Message-ID: <6525698B.002ADFCF.00@sampark.hss.hns.com> Subject: Re: [SIP] Discussion Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 2 Nov 2000 13:16:35 +0530 Just looking at the Via header host list to see if this is a loop is not enough. You need to look into the branchid to make sure that the current request URI is the same as the original one (which is reflected in the branchid computation). If a same message reaches the same proxy, but with a different request-URI, it should be processed normally by the proxy and not considered as a loop. (this is called a sprial loop) For an example of when a spiral might occur, Im attaching a small except from the "via loop detection and proxies" thread that was discussed a while ago: jdrosen@dynamicsoft.com wrote: "Its quite problematic for forwarding services. Lets say I forward calls from jdrosen@lucent.com to my secretary, secretary@lucent.com. You actually want the proxy to loop the request to itself in this case. As you say, the request URI is different, so its not really a loop; its a "spiral"." james> Is the hash is easy to james> implement? Could anyone give me advice on this? MD5 alogrithm is simple to implement and I think MD5 is available in Public domain too (?). one way to make a hash is to simply strcat From+To+CallId+CSeq+ReqUri and pass it to MD5Encode which will return you a digest value that you can use as the one of the branchi components. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems james jack on 11/02/2000 11:10:38 AM To: SIP@lists.bell-labs.com cc: Subject: [SIP] Discussion Dear All: I have one question to discuss. In order to detect loop, RFC2543bis02 page 81 says"A request has been looped if the server finds its own address in the Via header field and the hash computation over the fields enumerated in Section 6.46.6 yields the same value as the hash part of the ??branch?? parameter in the Via entry containing the proxy server??s address.", Page 59"In order to be able to both detect loops and associate responses with the corresponding request, the parameter SHOULD consist of two parts separable by the implementation. One part, used for loop detection (Section 12.3.1), MAY be computed as a cryptographic hash of the To, From, Call-ID header fields, the Request-URI of the request received (before translation) and the sequence number from the CSeq header field. The algorithm used to compute the hash is implementation-dependent, but MD5 [38], expressed in hexadecimal, is a reasonable choice.". According to my knowledge, it is necessary to detect the Via to find whether loop or not, why use these parameters to detect loop, Is the hash is easy to implement? Could anyone give me advice on this? Thanks a lot! Best regards! Yours: James __________________________________________________ Do You Yahoo!? From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 05:45: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 FAA04889 for ; Thu, 2 Nov 2000 05:45:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9BBCF44337; Thu, 2 Nov 2000 04:45:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ss3000e.cselt.it (ss3000e.cselt.it [163.162.41.5]) by lists.bell-labs.com (Postfix) with ESMTP id 1B10344336 for ; Thu, 2 Nov 2000 04:44:19 -0500 (EST) Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G3E00I9P8D0BM@ss3000e.cselt.it> for SIP@lists.bell-labs.com; Thu, 2 Nov 2000 11:41:25 +0100 (MET) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id <47JRRHR6>; Thu, 02 Nov 2000 11:44:19 +0100 Content-return: allowed From: De Nitto Grazia Subject: [SIP] un-subscribe To: "'SIP@lists.bell-labs.com'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 02 Nov 2000 11:41:24 +0100 un-subscribe _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 06:00: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 GAA08192 for ; Thu, 2 Nov 2000 06:00:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B23BF44359; Thu, 2 Nov 2000 05:00:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id B9ED644337 for ; Thu, 2 Nov 2000 04:59:08 -0500 (EST) Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA2AxcC18617 for ; Thu, 2 Nov 2000 16:29:38 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525698B.003B535D ; Thu, 2 Nov 2000 16:17:59 +0530 X-Lotus-FromDomain: HSS From: rvij@hss.hns.com To: "'SIP@lists.bell-labs.com'" Message-ID: <6525698B.003B5177.00@sandesh.hss.hns.com> Subject: [SIP] un-subscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 2 Nov 2000 16:23:33 +0530 un-subscribe _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 08:25:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13340 for ; Thu, 2 Nov 2000 08:25:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A10A444337; Thu, 2 Nov 2000 07:25:06 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 3D6F644336 for ; Thu, 2 Nov 2000 07:24:09 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Nov 2 08:23:48 EST 2000 Received: by lists.bell-labs.com (Postfix) id 91FC144380; Thu, 2 Nov 2000 08:10:39 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 5387D4437D for ; Thu, 2 Nov 2000 08:10:39 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id HAA01150; Thu, 2 Nov 2000 07:10:37 -0600 Cc: "'sip@lists.bell-labs.com'" Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id HAA01143; Thu, 2 Nov 2000 07:10:35 -0600 Message-ID: <3A0167C9.51096C05@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: Sandeep Sahai Original-CC: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Sip- Message OPTION 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, 02 Nov 2000 07:10:33 -0600 Content-Transfer-Encoding: 7bit Sandeep Sahai wrote: > > Hi, > > Can any one tell me what is the sip-message for OPTION look like. > > I was trying to find the same in the call flow diagram document , but > I cannot see an example for an OPTION sip message. > > So, please let me an example of sip-message for OPTION. It is in the bis (Section 16, I think). - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software & eServices Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 09:00: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 JAA23564 for ; Thu, 2 Nov 2000 09:00:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A25EA44337; Thu, 2 Nov 2000 08:00:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.218.19.194]) by lists.bell-labs.com (Postfix) with ESMTP id A1EE34433F for ; Wed, 1 Nov 2000 11:09:28 -0500 (EST) Received: from hafez (csp@localhost) by hafez.east.isi.edu (8.11.0/8.11.0) with ESMTP id eA1H9HJ01116; Wed, 1 Nov 2000 12:09:17 -0500 Message-Id: <200011011709.eA1H9HJ01116@hafez.east.isi.edu> To: duncant@mitre.org Cc: sip@lists.bell-labs.com Subject: Re: [SIP] What is the status of SAP? In-Reply-To: Your message of "Wed, 01 Nov 2000 12:03:36 EST." <3A004CE8.522AD4C1@mitre.org> From: Colin Perkins Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 01 Nov 2000 12:09:17 -0500 --> Duncan Thomson writes: >RFC 2543 (SIP) references the session announcement protocol (SAP), which exists only as a 1996 Int >ernet Draft, that is, a "work in progress". So is SAP actually a "work in progress"? If so, why >hasn't anything been published on it since the 1996 Internet Draft? Or is it considered obsolete? It was recently published as RFC 2974. Colin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 09:01: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 JAA24034 for ; Thu, 2 Nov 2000 09:01:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4DBF244349; Thu, 2 Nov 2000 08:00:22 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from salvelinus.brooktrout.com (unknown [204.176.205.6]) by lists.bell-labs.com (Postfix) with ESMTP id 9A66644336 for ; Wed, 1 Nov 2000 15:46:29 -0500 (EST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by salvelinus.brooktrout.com (8.9.3/8.9.3/BTI-2.1) with ESMTP id QAA20295; Wed, 1 Nov 2000 16:34:42 -0500 (EST) Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 16:46:35 -0500 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F0347F2F0@nhmail1.admin.brooktrout.com> From: James Rafferty To: "'David Yon'" , Jean-Francois Mule , ietf-fax@imc.org Cc: sip@lists.bell-labs.com, "'Glenn Parsons'" , "'Herman Silbiger'" Subject: RE: [SIP] RE: Request for information on using T.30/T.37/T.38 wit h SIP/SDP/ RTP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 1 Nov 2000 16:46:33 -0500 To all - The registration from ITU-T SG8 for IANA as related to SDP was related to the Approval last February of Annex D to T.38, which defines how to use SIP/SDP with T.38 for facsimile session control. T.38 needs to support both UDP and TCP modes of operation, hence the need for the SDP extension to support TCP (Glenn Parsons of Nortel was the editor). So, the methods for using TCP within SDP for T.38 session control purposes have been described in detail in the T.38 Annex D. So, I'd suggest that people who want to write ID's related to this, take a look at what is in the T.38 Annex D (TIES users can read it as TD262rev2 in the SG8 informal FTP area). There is also a small amendment to T.38 annex D (see Com8-114) which will be reviewed at the SG16 meeting during the week of Nov 13-17. I just checked on the ITU site and notice that T.38 Amendment 2 is not published yet, so the TD262rev2 above is the only access to that text at the moment. Hopefully, this will change soon. James * ----------------------------------- James Rafferty Senior Product Manager, IP Telephony jraff@brooktrout.com Brooktrout Technology 410 First Avenue Needham, MA 02494 USA Phone: +1-781-433-9462 Fax: 781-433-9268 www.brooktrout.com Your Hook into the New Network(SM) > -----Original Message----- > From: David Yon [mailto:yon@dialout.net] > Sent: Monday, October 30, 2000 3:54 PM > To: Jean-Francois Mule; ietf-fax@imc.org > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] RE: Request for information on using T.30/T.37/T.38 > with SIP/SDP/ RTP > > > I know that the I-D specifically defers the discussion of > media transport > using TCP rather than UDPTL, but at the same time it also > refers to a new > token "TCP" to be registered with IANA for use in SDP. I am > of the opinion > that simply specifying "TCP" is insufficient to describe how > TCP-based > Media Transport is to be negotiated between two endpoints. > > I've submitted an Internet Draft for the MMUSIC group which > will hopefully > be available in the IETF I-D area soon, but for the moment it > can be read here: > ftp://ftp.dialout.net/drafts/draft-ietf-mmusic-sdp-tcpmedia-00.txt So, in regards to the SIP/T.38 I-D, my only comment would be that it take into account the I-D on SDP/TCP. Or at the very least, participate with better defining the SDP/TCP I-D such that is meets the needs of SIP/T.38 when using TCP for Media Transport. As such, any comments on the I-D above would be greatly appreciated. Again, hopefully the draft will be in the IETF area soon, I don't know why it is taking so long to work through the queue. At 02:26 PM 10/27/00 -0700, Jean-Francois Mule wrote: >There is an Internet-Draft on SIP and T.38 fax calls at >http://search.ietf.org/internet-drafts/draft-mule-sip-t38callflows-00.txt >It deals with how to negotiate a t.38 fax calls using sip as a signaling >protocol (including switch over from audio/rtp to data/t38), the SDP >attributes that itu-t sg-8 has registered with IANA. Comments are >appreciated on this Internet-Draft. > > David Yon Chief Technical Officer Dialout.Net, Inc. yon@dialout.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 09:05: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 JAA24885 for ; Thu, 2 Nov 2000 09:05:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A98CA4436C; Thu, 2 Nov 2000 08:00:32 -0500 (EST) 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 DA9F544336 for ; Wed, 1 Nov 2000 16:05:26 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA26647 for ; Wed, 1 Nov 2000 17:05:18 -0500 (EST) 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 RAA04140 for ; Wed, 1 Nov 2000 17:05:21 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 17:04:46 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E968@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" 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] Working Group Last Call on draft-ietf-sip-session-timer-03.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 1 Nov 2000 17:05:11 -0500 We would like to announce a working group last call on draft-ietf-sip-session-timer-03.txt Last Call will end in two weeks. If you have any comments or concerns on this draft, or do not believe it is ready to be sent to the IESG for promotion to a standards track RFC, please send your comments to the list now Thank you Brian Rosen Dean Willis Joerg Ott _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 09:09: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 JAA26208 for ; Thu, 2 Nov 2000 09:09:49 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D243C44377; Thu, 2 Nov 2000 08:05:06 -0500 (EST) 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 8E62A44375 for ; Thu, 2 Nov 2000 08:04:12 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04658 for ; Thu, 2 Nov 2000 09:04:01 -0500 (EST) 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 JAA01709 for ; Thu, 2 Nov 2000 09:04:03 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 09:03:25 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E979@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" 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] Working Group Last Call on draft-ietf-sip-session-timer-03.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 2 Nov 2000 09:03:58 -0500 We would like to announce a working group last call on draft-ietf-sip-session-timer-03.txt Last Call will end in two weeks. If you have any comments or concerns on this draft, or do not believe it is ready to be sent to the IESG for promotion to a standards track RFC, please send your comments to the list now Thank you Brian Rosen Dean Willis Joerg Ott _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 10:58:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01788 for ; Thu, 2 Nov 2000 10:58:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6271F44339; Thu, 2 Nov 2000 09:58:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id 911C644336 for ; Thu, 2 Nov 2000 09:57:57 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 2 Nov 2000 15:48:00 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-29) id PAA07582; Thu, 2 Nov 2000 15:47:59 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025698B.0056C2CA ; Thu, 2 Nov 2000 15:47:39 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Robin Escolme" To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Message-ID: <8025698B.0056BF41.00@marconicomms.com> Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 2 Nov 2000 15:44:48 +0000 Hi, Some comments and questions : Section 5.2, CASE I - UAC supports session timers. The text states "In this case the proxy remembers that it inserted a Session-Expires header into the request and that the UAC supported sesion timer". The proxy may not have inserted a Session-Expires header - it would only have done so if the there wasn't one in the request from the UAC. CASE II - UAC Doesn't support, UAS doesn't support. There is, presumably, nothing to stop the proxy, if its policy dictates, from running a local session timer, the expiration of which would result in it de-allocating any resources - and in particular, closing any pin-holes opened across a firewall, with no indication at all to the end points. Whilst this isn't very nice for the end points, since their RTP packets would suddenly cease, the proxy is trying to protect it's network resources from unreliable end-points. The session timer used be longer that normal, given there is no opportunity to refresh. Alternatively, cannot the proxy issue a re-INVITE to each UA, using the same SDP used orginally? Section 6, Para 2 states "If the the UAS places a Session-Expires header into the response, and the request contained a Supported header with the value "timer",.......". This implies that the UAS may place a Session-Espires header into the response when the request did not contain a Supported header with the value "timer". However, the table further down says that if the request contained neither a Supported header with the value "timer", nor a Session-Expires header, there there will be no timers. Surely, if the UAS supports session timers it can place a Session-Expires header in the response, so that it indicates to proxies that it is running a session timer. If this is the case, then the behavoir in the foirst row of this table should indicate that the UAS MAY add a session-Expires header to the response. This then equates to CASE III in section 5.2. Section 6, last para suggests that a 200 OK in response to a re-INVITE may not contain a Session-Expire header. How can this be, unless a proxy or the UAC has removed it, which I thought was not allowed? Section 8.5 - call flow for re-INVITE. The Calling UA send the INVITE to the SPS with a Session-Expires header. The note against the next message, INVITE from SPS to Called UA says the SPS adds the S-E header, but it was already there. General - ther terms UAC and UAS I have taken to be synonymous with Calling UAC and Called UAC, respectively. The document makes use of both terms at varying times. Are these terms interchangeable or is there some implied difference. Section 9 of RFC2543bis02 lists abbreviated forms for common header fields. The session timer feature is valuable and may be insisted upon by many networks, bringing the Session Expires header into common use. You should consider an abbreviated form. Hope these make sense. Robin Escolme Marconi 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 Nov 2 13:50: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 NAA15679 for ; Thu, 2 Nov 2000 13:50:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7E2CD44337; Thu, 2 Nov 2000 12:50:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 6716C44336 for ; Thu, 2 Nov 2000 12:49:06 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id NAA00918; Thu, 2 Nov 2000 13:44:12 -0500 (EST) Message-ID: <3A01B716.781293AB@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=iso-8859-1 Subject: [SIP] Content-Length values in RFC and call flows examples Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 02 Nov 2000 13:48:54 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id NAA15679 Here is a straightforward question regarding the examples in the RFC and sip call flows documents. Are the Content-Length values computed on the basis of CR-LF (2 characters) for newline? (i.e. DOS vs UNIX convention)? Thank you in advance for your replies. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"şX¬¶ÏÛzYÿ•¦ìıÊ&†ÛiÿÿåŠËlı·¥—ùZnÏÜ¢oæj)fjåŠËbú? From sip-admin@lists.bell-labs.com Thu Nov 2 13:57:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17282 for ; Thu, 2 Nov 2000 13:57:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0D00D4433F; Thu, 2 Nov 2000 12:57:06 -0500 (EST) 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 CE4D244337 for ; Thu, 2 Nov 2000 12:56:26 -0500 (EST) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id KAA00429; Thu, 2 Nov 2000 10:59:52 -0800 Message-ID: <3A01B9A8.93C81DB6@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Content-Length values in RFC and call flows examples References: <3A01B716.781293AB@nist.gov> Content-Type: multipart/mixed; boundary="------------A89B8CF0BA7020851A790200" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 02 Nov 2000 10:59:52 -0800 This is a multi-part message in MIME format. --------------A89B8CF0BA7020851A790200 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Greetings: "M. Ranganathan" wrote: > Here is a straightforward question regarding the examples in the RFC and > sip call flows documents. > > Are the Content-Length values computed on the basis of CR-LF (2 > characters) for newline? (i.e. DOS vs UNIX convention)? Yes. Regards, Bobby.Sardana@mobilerain.com > > > Thank you in advance for your replies. > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > Hfæj)b? b²Ô^>X¬¶ÆŞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèşÈ© --------------A89B8CF0BA7020851A790200 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 --------------A89B8CF0BA7020851A790200-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 14:03: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 OAA18959 for ; Thu, 2 Nov 2000 14:03:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 281624434E; Thu, 2 Nov 2000 13:03:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E16974434D for ; Thu, 2 Nov 2000 13:02:12 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA09410; Thu, 2 Nov 2000 14:04:23 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YKQR>; Thu, 2 Nov 2000 13:57:56 -0500 Message-ID: From: Igor Slepchin To: "'mranga@nist.gov'" , sip@lists.bell-labs.com Subject: RE: [SIP] Content-Length values in RFC and call flows examples 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, 2 Nov 2000 13:57:54 -0500 > Here is a straightforward question regarding the examples in > the RFC and > sip call flows documents. > > Are the Content-Length values computed on the basis of CR-LF (2 > characters) for newline? (i.e. DOS vs UNIX convention)? No. Content-Length is computed based on the real length of the payload, whether it uses CRLF, LF, CR or anything else to terminate lines. Thank you, 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 Thu Nov 2 15:11: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 PAA07058 for ; Thu, 2 Nov 2000 15:11:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C2A144337; Thu, 2 Nov 2000 14:11:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 5D34E44362 for ; Thu, 2 Nov 2000 08:30:50 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA08431; Thu, 2 Nov 2000 09:30:36 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA06452; Thu, 2 Nov 2000 09:30:35 -0500 (EST) Message-ID: <3A00FA21.C2734168@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: antti.vaha-sipila@nokia.com Cc: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Comments on 2806bis-00 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 01 Nov 2000 21:22:41 -0800 Content-Transfer-Encoding: 7bit One very basic comment is that the current RFC 2806 does not follow the normal URI syntax description rules. This is very confusing, as it leads to duplicating the description of escaping, with different rules and, as witnessed on this list a few months ago, weeks of confusion as the two "worlds" are mentally merged. I would strongly recommend that the ABNF be revised to conform to the standard way of specifying URL content. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 15:12:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07541 for ; Thu, 2 Nov 2000 15:12:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34BAF44342; Thu, 2 Nov 2000 14:11:17 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1ACBE44336 for ; Thu, 2 Nov 2000 11:00:48 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA18598 for ; Thu, 2 Nov 2000 12:00:40 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA06805 for ; Thu, 2 Nov 2000 12:00:40 -0500 (EST) Message-ID: <3A01C8D6.8906245C@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] IANA SIP header registration Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 02 Nov 2000 12:04:38 -0800 Content-Transfer-Encoding: 7bit IANA has agreed to register SIP header field names and compact forms to minimize the chance for collisions. I've put together an initial list for RFC2543 and draft-ietf-sip-rfc2543bis, session timers and 100rel, but headers from other drafts need to be added. The current list is at http://www.cs.columbia.edu/sip/headers.txt. Please send me corrections and additions. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 15:19: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 PAA09052 for ; Thu, 2 Nov 2000 15:19:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2772144342; Thu, 2 Nov 2000 14:19:07 -0500 (EST) 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 B496D44340 for ; Thu, 2 Nov 2000 14:18:41 -0500 (EST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id UAA07775; Thu, 2 Nov 2000 20:19:37 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 02 Nov 2000 20:18:21 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 12:17:36 -0800 Message-ID: From: "Singh, Manish" To: "'Robin Escolme'" , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 2 Nov 2000 12:17:08 -0800 Hi, Sectoin 4, UAC behavior states : "Note that it is possible that the calling UA is generating refreshes, and then it receives a re-INVITE. After following the rules for UAS described below, the calling UA now determines it is not supposed to generate refreshes..........." Is their a specific reason for allowing the master switchover for generating the re-INVITES? After the initial negotation, if the UAC was responsible for generating re-INVITES, why would UAS in the middle of a session like to take control? Can we add an Example flow for this scenario in section 8 of the draft. -Thanks, Manish Singh -----Original Message----- From: Robin Escolme [mailto:Robin.Escolme@marconi.com] Sent: Thursday, November 02, 2000 7:45 AM To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt Hi, Some comments and questions : Section 5.2, CASE I - UAC supports session timers. The text states "In this case the proxy remembers that it inserted a Session-Expires header into the request and that the UAC supported sesion timer". The proxy may not have inserted a Session-Expires header - it would only have done so if the there wasn't one in the request from the UAC. CASE II - UAC Doesn't support, UAS doesn't support. There is, presumably, nothing to stop the proxy, if its policy dictates, from running a local session timer, the expiration of which would result in it de-allocating any resources - and in particular, closing any pin-holes opened across a firewall, with no indication at all to the end points. Whilst this isn't very nice for the end points, since their RTP packets would suddenly cease, the proxy is trying to protect it's network resources from unreliable end-points. The session timer used be longer that normal, given there is no opportunity to refresh. Alternatively, cannot the proxy issue a re-INVITE to each UA, using the same SDP used orginally? Section 6, Para 2 states "If the the UAS places a Session-Expires header into the response, and the request contained a Supported header with the value "timer",.......". This implies that the UAS may place a Session-Espires header into the response when the request did not contain a Supported header with the value "timer". However, the table further down says that if the request contained neither a Supported header with the value "timer", nor a Session-Expires header, there there will be no timers. Surely, if the UAS supports session timers it can place a Session-Expires header in the response, so that it indicates to proxies that it is running a session timer. If this is the case, then the behavoir in the foirst row of this table should indicate that the UAS MAY add a session-Expires header to the response. This then equates to CASE III in section 5.2. Section 6, last para suggests that a 200 OK in response to a re-INVITE may not contain a Session-Expire header. How can this be, unless a proxy or the UAC has removed it, which I thought was not allowed? Section 8.5 - call flow for re-INVITE. The Calling UA send the INVITE to the SPS with a Session-Expires header. The note against the next message, INVITE from SPS to Called UA says the SPS adds the S-E header, but it was already there. General - ther terms UAC and UAS I have taken to be synonymous with Calling UAC and Called UAC, respectively. The document makes use of both terms at varying times. Are these terms interchangeable or is there some implied difference. Section 9 of RFC2543bis02 lists abbreviated forms for common header fields. The session timer feature is valuable and may be insisted upon by many networks, bringing the Session Expires header into common use. You should consider an abbreviated form. Hope these make sense. Robin Escolme Marconi 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 Thu Nov 2 22:12:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10535 for ; Thu, 2 Nov 2000 22:12:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 75C1844337; Thu, 2 Nov 2000 21:12:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sargasso.cse.msu.edu (sargasso.cse.msu.edu [35.9.20.10]) by lists.bell-labs.com (Postfix) with ESMTP id D14FD44336 for ; Thu, 2 Nov 2000 21:11:36 -0500 (EST) Received: from arctic.cse.msu.edu (arctic.cse.msu.edu [35.9.20.20]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with ESMTP id WAA02369 for ; Thu, 2 Nov 2000 22:11:30 -0500 (EST) From: Tajindrapal Singh Received: (from singhtaj@localhost) by arctic.cse.msu.edu (8.8.8/8.8.8) id WAA05863 for sip@lists.bell-labs.com; Thu, 2 Nov 2000 22:11:30 -0500 (EST) Message-Id: <200011030311.WAA05863@arctic.cse.msu.edu> To: sip@lists.bell-labs.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Question on SIPd Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 2 Nov 2000 22:11:30 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, Just wanted to know whether you need to have root access in order to install the sip server ? Any help will be greatly appreciated. Thanks T.Singh _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 2 23:09: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 XAA17893 for ; Thu, 2 Nov 2000 23:09:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B211E44337; Thu, 2 Nov 2000 22:09:06 -0500 (EST) 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 780CE44336 for ; Thu, 2 Nov 2000 22:08:03 -0500 (EST) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id for ; Thu, 2 Nov 2000 20:05:37 -0800 From: "Simon Barber" To: "Sip List" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20001102000915.C1402@div8.net> Subject: [SIP] A replacement for e-mail polling with POP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 2 Nov 2000 20:10:30 -0800 Content-Transfer-Encoding: 7bit Use SMTP to deliver e-mail to the UA (push), and use SIP REGISTER to update the UA's address in the final MTA. Send a REGISTER message with To: mailto:simon@firetalk.com Contact: mailto:a.workstation.firetalk.com:2000 Simon. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 02:37:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03892 for ; Fri, 3 Nov 2000 02:37:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9EE9F44337; Fri, 3 Nov 2000 01:37:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 46EC744336 for ; Fri, 3 Nov 2000 01:36:00 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id BAA28286; Fri, 3 Nov 2000 01:35:51 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eA37Xqk24915; Fri, 3 Nov 2000 01:33:52 -0600 (CST) Received: from ericsson.com (kipe51.eraj.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id BAA10249; Fri, 3 Nov 2000 01:35:49 -0600 (CST) Message-ID: <3A026AD3.70E41EC@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: Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: Re: [SIP] IANA SIP header registration References: <3A01C8D6.8906245C@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 03 Nov 2000 08:35:47 +0100 Content-Transfer-Encoding: 7bit Does this mean open season on compact forms? I really hope not. In fact, I wish they would go away altogether. I don't want to re-open this debate, but I would like to dam the flood of new compact forms. Am I the only one who feels this way? /sean Henning Schulzrinne wrote: > IANA has agreed to register SIP header field names and compact forms to > minimize the chance for collisions. I've put together an initial list > for RFC2543 and draft-ietf-sip-rfc2543bis, session timers and 100rel, > but headers from other drafts need to be added. The current list is at > http://www.cs.columbia.edu/sip/headers.txt. > > Please send me corrections and additions. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 3 02:48: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 CAA07375 for ; Fri, 3 Nov 2000 02:48:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F312C44344; Fri, 3 Nov 2000 01:48:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 248484433C for ; Fri, 3 Nov 2000 01:47:45 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA14113; Fri, 3 Nov 2000 02:45:55 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YLPD>; Fri, 3 Nov 2000 02:39:26 -0500 Message-ID: From: Jonathan Rosenberg To: "'Thys Nel'" , "'Billy Biggs'" , archow@hss.hns.com Cc: "'Sandeep Sahai'" , "'SIP List'" Subject: RE: [SIP] Sip- Message OPTION 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, 3 Nov 2000 02:39:21 -0500 All servers (UAS, registrar) should answer a OPTIONS with a 200 OK with the following headers added to the response: Allow, listing the supported methods, Accept, listing the support MIME types, and Supported, listing the supported extensions. A UAS could also insert SDP listing its codecs. How such SDP is formatted has never been defined, and to my knowledge, no one is yet doing this. We'll define something in bis. As an example for a registrar response to OPTIONS: SIP/2.0 200 OK From: sip:querier@company.com To: sip:registardomain.com;tag=9378asd0asd7asd Call-ID: a90sda08shd@1.2.3.4 CSeq: 1 REGISTER Via: SIP/2.0/UDP host.company.com Accept: application/cpl+xml Allow: OPTIONS, REGISTER, CANCEL Supported: pref Content-Length: 0 This registar supports uploads of CPL, and also the caller preferences extension. -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: Thys Nel [mailto:thys@parsec.co.za] > Sent: Thursday, November 02, 2000 1:48 AM > To: 'Billy Biggs'; archow@hss.hns.com > Cc: 'Sandeep Sahai'; 'SIP List' > Subject: RE: [SIP] Sip- Message OPTION > > > Does anyone have examples of messages flows with OPTIONS > processed by a > registrar server? The only example in the RFC is between 2 > user agents, but > the RFC states that a registrar must also support it. I can't > seem to find > any description of when a registrar should respond to an > OPTIONS request. > > Thys > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Billy Biggs > > Sent: 02 November 2000 8:17 > > To: archow@hss.hns.com > > Cc: Sandeep Sahai; SIP List > > Subject: Re: [SIP] Sip- Message OPTION > > > > > > Note that this should be cleaned up. There is no Via or > CSeq in the > > response, the CSeq in the request starts at 1, the From has > > no tag, and there > > is no Content-Length. > > > > > C->S: OPTIONS sip:bob@example.com SIP/2.0 > > > Via: SIP/2.0/UDP cat.wonderland.com > > > From: Alice > > > To: Bob > > > Call-ID: 6378@cat.wonderland.com > > > CSeq: 1 OPTIONS > > > Accept: application/sdp > > > > > > S->C: SIP/2.0 200 OK > > > From: Alice > > > To: Bob ;tag=376364382 > > > Call-ID: 6378@cat.wonderland.com > > > Content-Length: 81 > > > Content-Type: application/sdp > > > > > > v=0 > > > o=alice 3149329138 3149329165 IN IP4 24.124.37.3 > > > s=Security problems > > > t=3149328650 0 > > > c=IN IP4 24.124.37.3 > > > m=audio 0 RTP/AVP 0 1 3 99 > > > a=rtpmap:0 PCMU/8000 > > > a=rtpmap:1 1016/8000 > > > a=rtpmap:3 GSM/8000 > > > a=rtpmap:99 SX7300/8000 > > > m=video 0 RTP/AVP 31 34 > > > a=rtpmap:31 H261/90000 > > > a=rtpmap:34 H263/90000 > > > > -- > > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 3 02:51: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 CAA08579 for ; Fri, 3 Nov 2000 02:51:49 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E212C4434C; Fri, 3 Nov 2000 01:49:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EB5DB4433C for ; Fri, 3 Nov 2000 01:48:13 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA14118; Fri, 3 Nov 2000 02:50:25 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YLP1>; Fri, 3 Nov 2000 02:43:56 -0500 Message-ID: From: Jonathan Rosenberg To: Igor Slepchin , "'mranga@nist.gov'" , sip@lists.bell-labs.com Subject: RE: [SIP] Content-Length values in RFC and call flows examples 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, 3 Nov 2000 02:43:52 -0500 > -----Original Message----- > From: Igor Slepchin [mailto:ISlepchin@dynamicsoft.com] > Sent: Thursday, November 02, 2000 1:58 PM > To: 'mranga@nist.gov'; sip@lists.bell-labs.com > Subject: RE: [SIP] Content-Length values in RFC and call > flows examples > > > > Here is a straightforward question regarding the examples in > > the RFC and > > sip call flows documents. > > > > Are the Content-Length values computed on the basis of CR-LF (2 > > characters) for newline? (i.e. DOS vs UNIX convention)? > > No. Content-Length is computed based on the real length of > the payload, > whether it uses CRLF, LF, CR or anything else to terminate lines. Correct. Whatever the number of bytes are in the body, thats the content-length. The computation is independent of what the bytes represent. So, CR-LF is two bytes, CR is one, LF is one. -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 Nov 3 03:01: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 DAA11610 for ; Fri, 3 Nov 2000 03:01:20 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C5FE44354; Fri, 3 Nov 2000 01:57:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9854644337 for ; Fri, 3 Nov 2000 01:56:15 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA14162; Fri, 3 Nov 2000 02:58:25 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YLPP>; Fri, 3 Nov 2000 02:51:56 -0500 Message-ID: From: Jonathan Rosenberg To: "'Singh, Manish'" , "'Robin Escolme'" , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 02:51:53 -0500 > -----Original Message----- > From: Singh, Manish [mailto:manishs@trillium.com] > Sent: Thursday, November 02, 2000 3:17 PM > To: 'Robin Escolme'; Jonathan Rosenberg > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt > > > Hi, > > Sectoin 4, UAC behavior states : > > "Note that it is possible that the calling UA is generating > refreshes, and then it receives a re-INVITE. After following > the rules for UAS described below, the calling UA now determines > it is not supposed to generate refreshes..........." > > Is their a specific reason for allowing the master switchover > for generating the re-INVITES? After the initial negotation, if > the UAC was responsible for generating re-INVITES, why would UAS > in the middle of a session like to take control? The idea was just to make the whole process stateless, so that processing of a re-INVITE is absolutely the same as processing the initial INVITE. As a result of this choice, the roles will change over on re-INVITEs depending on what level of support each side has. If each side both supports session timer, the user sending the re-INVITE will become the one performing refreshes if the re-invite completes successfully. The stateless operation is needed, for example, to recover from crash-reboot cycles. I think this actually makes the implementation simpler, not more complex. > > Can we add an Example flow for this scenario in section 8 of the > draft. I will add text explaining the above, and also an example flow. -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 Nov 3 07:53: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 HAA01511 for ; Fri, 3 Nov 2000 07:53:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F93044337; Fri, 3 Nov 2000 06:53:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 24BEF44336 for ; Fri, 3 Nov 2000 06:52:43 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id GAA00476; Fri, 3 Nov 2000 06:52:29 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id GAA22323; Fri, 3 Nov 2000 06:52:29 -0600 (CST) Received: from ericsson.com (kipe51.eraj.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id GAA17598; Fri, 3 Nov 2000 06:52:27 -0600 (CST) Message-ID: <3A02B508.B766A2B2@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: antti.vaha-sipila@nokia.com Cc: sip@lists.bell-labs.com References: <3A00FA21.C2734168@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] More Comments on 2806bis-00 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 03 Nov 2000 13:52:25 +0100 Content-Transfer-Encoding: 7bit Another minor comment on RFC2806. The private-prefix syntax is defined as below. private-prefix = (%x21-22 / %x24-27 / %x2C / %x2F / %x3A / %x3C-40 / %x45-4F / %x51-56 / %x58-60 / %x65-6F / %x71-76 / %x78-7E) *(%x21-3A / %x3C-7E) ; Characters in URLs must follow escaping rules ; as explained in [RFC2396] Missing from this private-prefix are the following US-ASCII letters. I am assuming these are missing because they are valid dtmf-digit characters and you want to avoid ambiguity with the local-prefix (the global-prefix is unambiguous because of the leading '+') %x41 = 'A' %x42 = 'B' %x43 = 'C' %x44 = 'D' %x61 = 'a' %x62 = 'b' %x63 = 'c' %x64 = 'd' These likewise would have been omitted because of the conflict with the 'pause' and 'wait-for-dial-tone' that can also occur in the local-prefix. %x50 = 'P' %x57 = 'W' %x70 = 'p' %x77 = 'w' This unfortunately is a bit limiting for the private prefix. My suggestion is that rather than omitting these from the private-prefix, that you require the private-prefix to start with a special prefix as with the global-prefix. For this purpose I would recommend "_" (%x5F). The ABNF for private-prefix would then become: private-prefix = "_" 1*(token-char) This would be unambiguos and more flexible. The exact prefix to the private-prefix is not important. It could, for instance, also be "X-"|"x-". What is important is that the letters a-d, p, and w are not excluded. Regards, Sean -- Sean Olson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 08:18:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07016 for ; Fri, 3 Nov 2000 08:18:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6CCAC44337; Fri, 3 Nov 2000 07:18:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id CA19644336 for ; Fri, 3 Nov 2000 07:17:07 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 6FA2D4CE3B; Fri, 3 Nov 2000 08:17:02 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA29003; Fri, 3 Nov 2000 08:16:59 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id IAA01367; Fri, 3 Nov 2000 08:16:34 -0500 (EST) Message-Id: <200011031316.IAA01367@fish-ha.research.att.com> To: hgs@cs.columbia.edu Cc: sip@lists.bell-labs.com Subject: [SIP] Re: IANA SIP header registration Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 08:16:34 -0500 (EST) Following are the headers, methods, and option tags defined in the dcsgroup drafts. The draft names reflect the new names under which they will be submitted in the next week or so. Bill Marshall wtm@research.att.com ---Headers--- Anonymity draft-ietf-sip-privacy-00 Dcs-Billing-ID draft-dcsgroup-sip-proxy-proxy-03 Dcs-Billing-Info draft-dcsgroup-sip-proxy-proxy-03 Dcs-Gate draft-dcsgroup-sip-proxy-proxy-03 Dcs-Laes draft-dcsgroup-sip-proxy-proxy-03 Dcs-OSPS draft-dcsgroup-sip-proxy-proxy-03 Dcs-Redirect draft-dcsgroup-sip-proxy-proxy-03 Dcs-Trace-Party-ID draft-dcsgroup-sip-proxy-proxy-03 Media-Authorization draft-ietf-sip-call-auth-00 Remote-Party-ID draft-ietf-sip-privacy-00 State draft-ietf-sip-state-00 ---Methods--- COMET draft-ietf-sip-manyfolks-resource-00 ---Option tags--- dcs draft-dcsgroup-sip-proxy-proxy-03 privacy draft-ietf-sip-privacy-00 state draft-ietf-sip-state-00 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 08:36:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11045 for ; Fri, 3 Nov 2000 08:36:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 83E8444349; Fri, 3 Nov 2000 07:36:05 -0500 (EST) 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 8FAAF44344 for ; Fri, 3 Nov 2000 07:35:24 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 3 Nov 2000 13:35:19 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA18666; Fri, 3 Nov 2000 14:33:45 +0100 (BST) Message-ID: <3A02BEB9.3C43C77A@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sip List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] UAC Record Routing in draft-ietf-sip-call-flows-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 03 Nov 2000 13:33:45 +0000 Content-Transfer-Encoding: 7bit The way the UAC builds the Route on a final 200 response in 3.1.2 of the call flows draft doesn't look quite right ... 3.1.2 Successful SIP to SIP through two proxies User A Proxy 1 Proxy 2 User B | | | | | INVITE F1 | | | |--------------->| | | | 407 F2 | | | |<---------------| | | | ACK F3 | | | |--------------->| | | | INVITE F4 | | | |--------------->| INVITE F5 | | | (100) F6 |--------------->| INVITE F7 | |<---------------| (100) F8 |--------------->| | |<---------------| | | | | 180 F9 | | | 180 F10 |<---------------| | 180 F11 |<---------------| | |<---------------| | 200 F12 | | | 200 F13 |<---------------| | 200 F14 |<---------------| | |<---------------| | | | ACK F15 | | | |--------------->| ACK F16 | | | |--------------->| ACK F17 | | | |--------------->| F14 200 OK Proxy 1 -> A SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 Record-Route: , From: BigGuy To: LittleGuy ;tag=314159 Call-ID: 12345601@here.com CSeq: 1 INVITE Contact: LittleGuy Content-Type: application/sdp Content-Length: 134 v=0 o=UserB 2890844527 2890844527 IN IP4 there.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F15 ACK A -> Proxy 1 ACK sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 Route: , From: BigGuy To: LittleGuy ;tag=314159 Call-ID: 12345601@here.com CSeq: 1 ACK Content-Length: 0 The UAC should build the Route header in the ACK by copying the 200 response Record-Route header, reversing the order and then adding the Contact as the last entry. (Note the 1st entry in the Route is subsequently removed when the client actually sends F15). But in this case the last entry has become an IP address. Shouldn't the UAC just copy the Contact and not try and do any resolution of 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 Fri Nov 3 09:37:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28451 for ; Fri, 3 Nov 2000 09:37:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 50EF344337; Fri, 3 Nov 2000 08:37:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 2F51844336 for ; Fri, 3 Nov 2000 02:33:38 -0500 (EST) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eA38XWt25913 for ; Fri, 3 Nov 2000 09:33:32 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id eA38XWn12811 for ; Fri, 3 Nov 2000 09:33:32 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id JAA07430; Fri, 3 Nov 2000 09:33:27 +0100 (MET) Message-ID: <3A027852.79E76CC1@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Subject: Re: [SIP] IANA SIP header registration References: <3A01C8D6.8906245C@cs.columbia.edu> <8tu59o$1ae$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 03 Nov 2000 09:33:22 +0100 Content-Transfer-Encoding: 7bit Definitely not, I would also like them to disappear. Atleast not creating new ones. The gain compared to the rest of the message contents are not that much. To write 't:' instead of 'to:' or 'v:' instead of 'via:' doesn't really help much. I don't want to restart this discussion either only give indication that you are not the only one. I wonder if there are anyone at all using the compact form. /Bertil Sean Olson wrote: > > Does this mean open season on compact forms? I really hope not. > In fact, I wish they would go away altogether. I don't want to re-open > this debate, but I would like to dam the flood of new compact forms. > > Am I the only one who feels this way? > /sean > > Henning Schulzrinne wrote: > > > IANA has agreed to register SIP header field names and compact forms to > > minimize the chance for collisions. I've put together an initial list > > for RFC2543 and draft-ietf-sip-rfc2543bis, session timers and 100rel, > > but headers from other drafts need to be added. The current list is at > > http://www.cs.columbia.edu/sip/headers.txt. > > > > Please send me corrections and additions. > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > 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 Fri Nov 3 10:28: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 KAA10809 for ; Fri, 3 Nov 2000 10:28:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A637A44337; Fri, 3 Nov 2000 09:28:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A8C9544336 for ; Fri, 3 Nov 2000 09:27:42 -0500 (EST) Received: from CINQUECENTO ([63.110.3.156]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id KAA15992 for ; Fri, 3 Nov 2000 10:29:51 -0500 (EST) From: "Robert Sparks" To: Subject: compact headers (was RE: [SIP] IANA SIP header registration) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3A027852.79E76CC1@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 09:23:21 -0600 Content-Transfer-Encoding: 7bit Currently, draft-ietf-sip-guidelines-00 says Extensions that define new headers SHOULD define a compact form representation if the non-compact header is more than four characters. Header names SHOULD use ASCII characters. Header names are always case insensitive. Header values are generally case sensitive, with the exception of domain names which MUST be case insensitive. RjS > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Bertil Engelholm > Sent: Friday, November 03, 2000 2:33 AM > To: SIP@lists.bell-labs.com > Subject: Re: [SIP] IANA SIP header registration > > > Definitely not, I would also like them to disappear. > Atleast not creating new ones. The gain compared to > the rest of the message contents are not that much. > > To write 't:' instead of 'to:' or 'v:' instead of 'via:' > doesn't really help much. I don't want to restart this > discussion either only give indication that you are > not the only one. I wonder if there are anyone at all > using the compact form. > > /Bertil > > Sean Olson wrote: > > > > Does this mean open season on compact forms? I really hope not. > > In fact, I wish they would go away altogether. I don't want to re-open > > this debate, but I would like to dam the flood of new compact forms. > > > > Am I the only one who feels this way? > > /sean > > > > Henning Schulzrinne wrote: > > > > > IANA has agreed to register SIP header field names and > compact forms to > > > minimize the chance for collisions. I've put together an initial list > > > for RFC2543 and draft-ietf-sip-rfc2543bis, session timers and 100rel, > > > but headers from other drafts need to be added. The current list is at > > > http://www.cs.columbia.edu/sip/headers.txt. > > > > > > Please send me corrections and additions. > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Bertil Engelholm > AXE Research and Development voice : +46 8 727 3499 > SIP Security Fax : +46 8 647 8276 > S-126 25 Stockholm Sweden E-mail: > Bertil.Engelholm@uab.ericsson.se > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 10:46:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15068 for ; Fri, 3 Nov 2000 10:46:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93E3E44337; Fri, 3 Nov 2000 09:46:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 9771644336 for ; Fri, 3 Nov 2000 09:45:33 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id JAA29386; Fri, 3 Nov 2000 09:45:25 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eA3FhQk04796; Fri, 3 Nov 2000 09:43:26 -0600 (CST) Received: from ericsson.com (kipe51.eraj.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA24991; Fri, 3 Nov 2000 09:45:23 -0600 (CST) Message-ID: <3A02DD8E.ADD7C93@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: Robert Sparks Cc: SIP@lists.bell-labs.com Subject: Re: compact headers (was RE: [SIP] IANA SIP header registration) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 03 Nov 2000 16:45:19 +0100 Content-Transfer-Encoding: 7bit Thanks for pointing this out. What is the guideline for when we exhaust the 26 single-letter forms? Do we go to two-letter forms, three-letter forms, etc.? What is the point of diminishing returns here? /sean Robert Sparks wrote: > Currently, draft-ietf-sip-guidelines-00 says > > Extensions that define new headers SHOULD define a compact form > representation if the non-compact header is more than four > characters. Header names SHOULD use ASCII characters. Header names > are always case insensitive. Header values are generally case > sensitive, with the exception of domain names which MUST be case > insensitive. > > RjS > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Bertil Engelholm > > Sent: Friday, November 03, 2000 2:33 AM > > To: SIP@lists.bell-labs.com > > Subject: Re: [SIP] IANA SIP header registration > > > > > > Definitely not, I would also like them to disappear. > > Atleast not creating new ones. The gain compared to > > the rest of the message contents are not that much. > > > > To write 't:' instead of 'to:' or 'v:' instead of 'via:' > > doesn't really help much. I don't want to restart this > > discussion either only give indication that you are > > not the only one. I wonder if there are anyone at all > > using the compact form. > > > > /Bertil > > > > Sean Olson wrote: > > > > > > Does this mean open season on compact forms? I really hope not. > > > In fact, I wish they would go away altogether. I don't want to re-open > > > this debate, but I would like to dam the flood of new compact forms. > > > > > > Am I the only one who feels this way? > > > /sean > > > > > > Henning Schulzrinne wrote: > > > > > > > IANA has agreed to register SIP header field names and > > compact forms to > > > > minimize the chance for collisions. I've put together an initial list > > > > for RFC2543 and draft-ietf-sip-rfc2543bis, session timers and 100rel, > > > > but headers from other drafts need to be added. The current list is at > > > > http://www.cs.columbia.edu/sip/headers.txt. > > > > > > > > Please send me corrections and additions. > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Bertil Engelholm > > AXE Research and Development voice : +46 8 727 3499 > > SIP Security Fax : +46 8 647 8276 > > S-126 25 Stockholm Sweden E-mail: > > Bertil.Engelholm@uab.ericsson.se > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 10:55:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17257 for ; Fri, 3 Nov 2000 10:55:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1AD814434E; Fri, 3 Nov 2000 09:55:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id C6E8244336 for ; Fri, 3 Nov 2000 09:54:01 -0500 (EST) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eA3Frtt02086 for ; Fri, 3 Nov 2000 16:53:56 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id eA3Frtn27362 for ; Fri, 3 Nov 2000 16:53:55 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id QAA10389; Fri, 3 Nov 2000 16:53:54 +0100 (MET) Message-ID: <3A02DF8F.39D29807@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com References: <8t9q4j$chb$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Identification problem Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 03 Nov 2000 16:53:51 +0100 Content-Transfer-Encoding: 7bit Hi, Sofar noone have responded to the problem below so this third time I send it I try a new subject. I was hoping that some SIP responsible people would come up with a solution to the problem or atleast say if it is regarded as a problem or not. Since noone have given any solutions I'll give my view of what I beleave could be done. The first solution is to remove the text where it says that a UA should fill all Routes with values from CONTACT or FROM. Instead the original addresses should be kept. Personally I find it strange when you combine addresses (from CONTACT/FROM) with a port number from RECORD-ROUTE. This means that the total address now is completely useless. It looks to me that you try to avoid syntax changes in the protocol at all costs. I don't understand why a change in semantics is regarded as more backwards compatible than a change in the syntax ? I would have prefered to add a port number in the maddr parameter because that's where I beleave it belongs. The second solution is to make it possible for a server to add it's own parameter in RECORD-ROUTE and then get it back in the REQUEST. Today a UAS only supposed to copy maddr and port value from RECORD-ROUTE to ROUTE. If all parameters was copied instead it would be possible for a server to add anything it likes in RECORD-ROUTE and get it back again. I beleave this kind of solution have been discussed for states ? /Bertil Bertil Engelholm wrote: > > Hi again, > > I'm sorry to bring this up again but I just can't get things > to work in the correct way. I have read through the old threads > regarding this matter and still don't understand how it is > suppose to work. > > It's this example again : > > --------- -------- -------- > | a@c1 | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> | | > --------- (contact a@c1) | | | | > | p1 | | p2 | > --------- | | | | > | b@c2 | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- | | > --------- -------- -------- > > If P1 is stateful it might allocate one "call" state machine for > each path the "call" takes in P1 (s1 and s2 in the picture). > These two state machines are identified by the REQUEST-URI > that came in the two INVITEs since that's the only thing that > differs the two from each other. (topmost VIA also differs, > more about that later) > > P1 will now include the REQUEST-URI in the branch value it > generates so that the responses can be directed to the right > state machine when they arrive. And when the ACK is sent the > original REQUEST-URI from ROUTE is used. So no problems here. > > The problem I have is when b@C2 sends a new request (eg. BYE). > According to the specification b should/must/may (or whatever) > overwrite the REQUEST-URI in the ROUTE headers using the > REQUEST-URI from CONTACT or FROM. > > So how should P1 now be able to differ the two (BYE) requests > from each other ? The Original REQUEST-URI was the only thing > that P1 had to identify the two state machines. > > When reading the old threads regarding this matter I saw > something about using topmost VIA in some way, but how ? > > By using the topmost VIA you can see that they are two different > requests but how do you identify which state machine should receive > the first request. (Someone might argue that it doesn't matter but if > P1 controls a firewall it DO matter. Maybe not for BYE but for a > RE-INVITE it matters). > > -- > Bertil Engelholm > AXE Research and Development voice : +46 8 727 3499 > SIP Security Fax : +46 8 647 8276 > S-126 25 Stockholm Sweden E-mail: > Bertil.Engelholm@uab.ericsson.se > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 11:14: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 LAA22694 for ; Fri, 3 Nov 2000 11:14:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CA8A44353; Fri, 3 Nov 2000 10:14:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id E2C4C44336 for ; Fri, 3 Nov 2000 10:13:49 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA17801 for ; Fri, 3 Nov 2000 10:13:44 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eA3GBjk10140 for ; Fri, 3 Nov 2000 10:11:45 -0600 (CST) Received: from ericsson.com (kipe51.eraj.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA26491; Fri, 3 Nov 2000 10:13:40 -0600 (CST) Message-ID: <3A02E42F.39834C0@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: Bertil Engelholm Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] Identification problem References: <8t9q4j$chb$1@lux2.datacom-lab.uab.ericsson.se> <3A02DF8F.39D29807@uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 03 Nov 2000 17:13:36 +0100 Content-Transfer-Encoding: 7bit Bertil Engelholm wrote: > > The second solution is to make it possible for a server > to add it's own parameter in RECORD-ROUTE and then get > it back in the REQUEST. Today a UAS only supposed to > copy maddr and port value from RECORD-ROUTE to ROUTE. > If all parameters was copied instead it would be possible > for a server to add anything it likes in RECORD-ROUTE > and get it back again. I beleave this kind of solution > have been discussed for states ? > > /Bertil I was under the impression that the Record-Route was supposed to be copied in its entirety to Route: (with some modifications, but no exclusion of parameters). I don't see anything in section 6.34 about the exclusion of parameters other than the fact that proxies should not include a transport parameter. On the topic of states, I would prefer to see the use of the State: header for this purpose since it is more generic. You do point out one case where state/context information could be useful. /sean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 12:29:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13675 for ; Fri, 3 Nov 2000 12:29:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E4B644337; Fri, 3 Nov 2000 11:29:06 -0500 (EST) 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 8880544336 for ; Fri, 3 Nov 2000 11:28:24 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 3 Nov 2000 17:28:19 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id SAA09685; Fri, 3 Nov 2000 18:26:48 +0100 (BST) Message-ID: <3A02F557.E3BCB965@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: Bertil Engelholm Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] Identification problem References: <8t9q4j$chb$1@lux2.datacom-lab.uab.ericsson.se> <3A02DF8F.39D29807@uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 03 Nov 2000 17:26:47 +0000 Content-Transfer-Encoding: 7bit I am afraid I don't see a problem with the spec. Unless I am missing something what you are talking about is a call stateful proxy not just a plain transaction stateful one. The transaction stateful one is OK as the bis-02 change to make the Via branch param globally unique differentiates the otherwise isomorphic BYEs. A call stateful proxy needs to do accounting beyond proxy transaction state, e.g.To/From tags. This accounting will also need to cover matching the right call state machine to the right BYE. For example on a reverse leg BYE the call state machine created 2nd will get the BYE 1st. BTW the issues raised in the solutions have been raised before see the threads "Record-Route and maddr" and "transaction identification". Introducing the contemplated State header is a cleaner way of achieving the 2nd solution. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net Bertil Engelholm wrote: > > Hi, > > Sofar noone have responded to the problem below so this > third time I send it I try a new subject. I was hoping > that some SIP responsible people would come up with a > solution to the problem or atleast say if it is regarded > as a problem or not. > > Since noone have given any solutions I'll give my view > of what I beleave could be done. > > The first solution is to remove the text where it says > that a UA should fill all Routes with values from > CONTACT or FROM. Instead the original addresses should > be kept. Personally I find it strange when you combine > addresses (from CONTACT/FROM) with a port number from > RECORD-ROUTE. This means that the total address now is > completely useless. It looks to me that you try to > avoid syntax changes in the protocol at all costs. I > don't understand why a change in semantics is regarded > as more backwards compatible than a change in the syntax ? > > I would have prefered to add a port number in the > maddr parameter because that's where I beleave it belongs. > > The second solution is to make it possible for a server > to add it's own parameter in RECORD-ROUTE and then get > it back in the REQUEST. Today a UAS only supposed to > copy maddr and port value from RECORD-ROUTE to ROUTE. > If all parameters was copied instead it would be possible > for a server to add anything it likes in RECORD-ROUTE > and get it back again. I beleave this kind of solution > have been discussed for states ? > > /Bertil > > Bertil Engelholm wrote: > > > > Hi again, > > > > I'm sorry to bring this up again but I just can't get things > > to work in the correct way. I have read through the old threads > > regarding this matter and still don't understand how it is > > suppose to work. > > > > It's this example again : > > > > --------- -------- -------- > > | a@c1 | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> | | > > --------- (contact a@c1) | | | | > > | p1 | | p2 | > > --------- | | | | > > | b@c2 | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- | | > > --------- -------- -------- > > > > If P1 is stateful it might allocate one "call" state machine for > > each path the "call" takes in P1 (s1 and s2 in the picture). > > These two state machines are identified by the REQUEST-URI > > that came in the two INVITEs since that's the only thing that > > differs the two from each other. (topmost VIA also differs, > > more about that later) > > > > P1 will now include the REQUEST-URI in the branch value it > > generates so that the responses can be directed to the right > > state machine when they arrive. And when the ACK is sent the > > original REQUEST-URI from ROUTE is used. So no problems here. > > > > The problem I have is when b@C2 sends a new request (eg. BYE). > > According to the specification b should/must/may (or whatever) > > overwrite the REQUEST-URI in the ROUTE headers using the > > REQUEST-URI from CONTACT or FROM. > > > > So how should P1 now be able to differ the two (BYE) requests > > from each other ? The Original REQUEST-URI was the only thing > > that P1 had to identify the two state machines. > > > > When reading the old threads regarding this matter I saw > > something about using topmost VIA in some way, but how ? > > > > By using the topmost VIA you can see that they are two different > > requests but how do you identify which state machine should receive > > the first request. (Someone might argue that it doesn't matter but if > > P1 controls a firewall it DO matter. Maybe not for BYE but for a > > RE-INVITE it matters). > > > > -- > > Bertil Engelholm > > AXE Research and Development voice : +46 8 727 3499 > > SIP Security Fax : +46 8 647 8276 > > S-126 25 Stockholm Sweden E-mail: > > Bertil.Engelholm@uab.ericsson.se > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Bertil Engelholm > AXE Research and Development voice : +46 8 727 3499 > SIP Security Fax : +46 8 647 8276 > S-126 25 Stockholm Sweden E-mail: > Bertil.Engelholm@uab.ericsson.se > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 12:39: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 MAA16902 for ; Fri, 3 Nov 2000 12:39:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E22F44357; Fri, 3 Nov 2000 11:39:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 03B9944336 for ; Fri, 3 Nov 2000 11:38:32 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA18354; Fri, 3 Nov 2000 12:40:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YMK8>; Fri, 3 Nov 2000 12:34:13 -0500 Message-ID: From: Jonathan Rosenberg To: "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: RE: [SIP] Identification problem MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 12:34:03 -0500 > -----Original Message----- > From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] > Sent: Friday, November 03, 2000 10:54 AM > To: SIP@lists.bell-labs.com > Subject: [SIP] Identification problem > > > Hi, > > Sofar noone have responded to the problem below so this > third time I send it I try a new subject. I was hoping > that some SIP responsible people would come up with a > solution to the problem or atleast say if it is regarded > as a problem or not. Well, back in the good old days, the SIP list generated just a few messages a day. I used to be able to respond almost immediately to every question. Now, as we approach the average of 30 messages per day, it is impossible for me, and many of the other SIP experts, to respond to every question on the list. Anyway, to answer your question, I can think of a few additional possibiltiies: 1. P1 use a different IP address (i.e., different maddr) as the request cycles through each time. This requires detection of the spiral and selection of a different address each time. This can be done statelessly, since the previous maddr inserted will appear somewhere in the Record-Route list when the request arrives again. This has the drawback of requiring a server to be configured with some number of IP addresses. 2. The difference between the requests coming to P1 the first time and second time is not just the top Via, but also the contents of the Route header. What you can do is this: when the response to the initial INVITE comes, the response carries the complete RR trace. You should be able to infer from the request and the response what the Route header set will look like by the time the messages reach P1, and this will be different for both times the request arrives. 3. As Sean has pointed out, the State header is another possibility. There is the unfortunate problem that this won't work if both UAs don't support the State header, so you pretty much need a non-State based solution anyway. Note that according to the spec now, the UAS does copy ONLY the maddr and port from the RR header; everything else comes from the Contact/From. > The first solution is to remove the text where it says > that a UA should fill all Routes with values from > CONTACT or FROM. Instead the original addresses should > be kept. Personally I find it strange when you combine > addresses (from CONTACT/FROM) with a port number from > RECORD-ROUTE. This means that the total address now is > completely useless. It looks to me that you try to > avoid syntax changes in the protocol at all costs. I > don't understand why a change in semantics is regarded > as more backwards compatible than a change in the syntax ? Because internal semantic processing does not require communications between devices. Thus, you can maintain interoperability. Its the "black box" paradigm; you have a hard time changing the interface between components in a system, but you can easily change the internal implementation and processing logic. That aside, the motivation for doing this oddball combination was to try and preserve a "fundamental invariant" of SIP, which was that the request URI should always refer to an entity that the request is actually addressed to. If the UAS simply uses the Record-Routes as is for the Route header, this won't be true. The result is a certain amount of brittleness. Now, I'm going to open a huge can of worms here. First, it seems I am in the minority of folks who think this approach (mixing the RR and From/Contact) is sensible. I'm willing to entertain the notion that preservation of a protocol invariant is less important than real protocol operational problems. Since the maintenance of this invariant is causing problems with spirals, perhaps it is not worth the pain, and we should return to the original notion of just using the list in the order you got it. Now, to make things more complex, we have a slight problem that record-routing has troubles when the request URI in the incoming request is not a SIP URL. Thats because, as you may recall, the RR process in a proxy is to COPY the request URI into the RR, and then modify the maddr and port. Now, maddr and port are SIP URL parameters. There are no such things for the tel URL, for example. Thus, record routing a request with a tel URL is a bit problematic. You basically need to convert it to a SIP URL first, or do something else. Converting everything to SIP URLs may not always be possible down the road. One can make the argument, and I would agree with it, that the IP address and port of the proxy are not URI parameters, but record-route header parameters. We did the hack of putting them in the URI maddr and port since this is backwards compatible. So, perhaps we should consider defining address and port record-route parameters. These would only be set when the request URI contained a non-SIP URL. Proxies would use these parameters if present for routing instead of the maddr and port in the URL. COmments? (I'm sure there are). -Jonathan R. > > I would have prefered to add a port number in the > maddr parameter because that's where I beleave it belongs. > > The second solution is to make it possible for a server > to add it's own parameter in RECORD-ROUTE and then get > it back in the REQUEST. Today a UAS only supposed to > copy maddr and port value from RECORD-ROUTE to ROUTE. > If all parameters was copied instead it would be possible > for a server to add anything it likes in RECORD-ROUTE > and get it back again. I beleave this kind of solution > have been discussed for states ? > > /Bertil > > Bertil Engelholm wrote: > > > > Hi again, > > > > I'm sorry to bring this up again but I just can't get things > > to work in the correct way. I have read through the old threads > > regarding this matter and still don't understand how it is > > suppose to work. > > > > It's this example again : > > > > --------- -------- -------- > > | a@c1 | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> | | > > --------- (contact a@c1) | | | | > > | p1 | | p2 | > > --------- | | | | > > | b@c2 | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- | | > > --------- -------- -------- > > > > If P1 is stateful it might allocate one "call" state machine for > > each path the "call" takes in P1 (s1 and s2 in the picture). > > These two state machines are identified by the REQUEST-URI > > that came in the two INVITEs since that's the only thing that > > differs the two from each other. (topmost VIA also differs, > > more about that later) > > > > P1 will now include the REQUEST-URI in the branch value it > > generates so that the responses can be directed to the right > > state machine when they arrive. And when the ACK is sent the > > original REQUEST-URI from ROUTE is used. So no problems here. > > > > The problem I have is when b@C2 sends a new request (eg. BYE). > > According to the specification b should/must/may (or whatever) > > overwrite the REQUEST-URI in the ROUTE headers using the > > REQUEST-URI from CONTACT or FROM. > > > > So how should P1 now be able to differ the two (BYE) requests > > from each other ? The Original REQUEST-URI was the only thing > > that P1 had to identify the two state machines. > > > > When reading the old threads regarding this matter I saw > > something about using topmost VIA in some way, but how ? > > > > By using the topmost VIA you can see that they are two different > > requests but how do you identify which state machine should receive > > the first request. (Someone might argue that it doesn't > matter but if > > P1 controls a firewall it DO matter. Maybe not for BYE but for a > > RE-INVITE it matters). > > > > -- > > Bertil Engelholm > > AXE Research and Development voice : +46 8 727 3499 > > SIP Security Fax : +46 8 647 8276 > > S-126 25 Stockholm Sweden E-mail: > > Bertil.Engelholm@uab.ericsson.se > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Bertil Engelholm > AXE Research and Development voice : +46 8 727 3499 > SIP Security Fax : +46 8 647 8276 > S-126 25 Stockholm Sweden E-mail: > Bertil.Engelholm@uab.ericsson.se > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > --- 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 Nov 3 12:43: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 MAA18211 for ; Fri, 3 Nov 2000 12:43:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 84A744435C; Fri, 3 Nov 2000 11:43:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0746C4435B for ; Fri, 3 Nov 2000 11:42:44 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA18418; Fri, 3 Nov 2000 12:44:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YMLM>; Fri, 3 Nov 2000 12:38:23 -0500 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson'" , Robert Sparks Cc: SIP@lists.bell-labs.com Subject: RE: compact headers (was RE: [SIP] IANA SIP header registration) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 12:38:20 -0500 > -----Original Message----- > From: Sean Olson [mailto:sean.olson@ericsson.com] > Sent: Friday, November 03, 2000 10:45 AM > To: Robert Sparks > Cc: SIP@lists.bell-labs.com > Subject: Re: compact headers (was RE: [SIP] IANA SIP header > registration) > > > Thanks for pointing this out. What is the guideline > for when we exhaust the 26 single-letter forms? > Do we go to two-letter forms, three-letter forms, etc.? > What is the point of diminishing returns here? We will end at 26. I suspect there are implementations that assume short form is one letter. Doing more defeats the purpose. We've had very mixed reactions on short form. There have been posters who wanted nothing but, and even insisted on it for things like CSeq, which is pretty short already. Others think its a waste. From an implementation perspective, its really a trivial amount of work either way. Its there; its not going away (there are implementations and there are people who send it). So, arguing about the merits of short form is moot. So, in an attempt to please some of the people some of the time, the guidelines draft has this little tidbit about when to define short form. I'll update it to indicate that the short form should always be a single character. -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 Nov 3 13:08: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 NAA23939 for ; Fri, 3 Nov 2000 13:08:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 07CBD44343; Fri, 3 Nov 2000 12:08:06 -0500 (EST) 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 0AEDB44337 for ; Fri, 3 Nov 2000 12:07:21 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 3 Nov 2000 18:07:15 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id TAA28177; Fri, 3 Nov 2000 19:05:42 +0100 (BST) Message-ID: <3A02FE76.685C2C2@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: Re: [SIP] Identification 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 03 Nov 2000 18:05:42 +0000 Content-Transfer-Encoding: 7bit Aplogies for a rushed post but I thought we had this covered already with the bis-02 introduction of global unique via branch param. http://lists.bell-labs.com/pipermail/sip/2000q3/002635.html Am I missing the problem? The other RR suggestions are certainly interesting ;) Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] > > Sent: Friday, November 03, 2000 10:54 AM > > To: SIP@lists.bell-labs.com > > Subject: [SIP] Identification problem > > > > > > Hi, > > > > Sofar noone have responded to the problem below so this > > third time I send it I try a new subject. I was hoping > > that some SIP responsible people would come up with a > > solution to the problem or atleast say if it is regarded > > as a problem or not. > > Well, back in the good old days, the SIP list generated just a few messages > a day. I used to be able to respond almost immediately to every question. > Now, as we approach the average of 30 messages per day, it is impossible for > me, and many of the other SIP experts, to respond to every question on the > list. > > Anyway, to answer your question, I can think of a few additional > possibiltiies: > > 1. P1 use a different IP address (i.e., different maddr) as the request > cycles through each time. This requires detection of the spiral and > selection of a different address each time. This can be done statelessly, > since the previous maddr inserted will appear somewhere in the Record-Route > list when the request arrives again. This has the drawback of requiring a > server to be configured with some number of IP addresses. > > 2. The difference between the requests coming to P1 the first time and > second time is not just the top Via, but also the contents of the Route > header. What you can do is this: when the response to the initial INVITE > comes, the response carries the complete RR trace. You should be able to > infer from the request and the response what the Route header set will look > like by the time the messages reach P1, and this will be different for both > times the request arrives. > > 3. As Sean has pointed out, the State header is another possibility. There > is the unfortunate problem that this won't work if both UAs don't support > the State header, so you pretty much need a non-State based solution anyway. > > Note that according to the spec now, the UAS does copy ONLY the maddr and > port from the RR header; everything else comes from the Contact/From. > > > The first solution is to remove the text where it says > > that a UA should fill all Routes with values from > > CONTACT or FROM. Instead the original addresses should > > be kept. Personally I find it strange when you combine > > addresses (from CONTACT/FROM) with a port number from > > RECORD-ROUTE. This means that the total address now is > > completely useless. It looks to me that you try to > > avoid syntax changes in the protocol at all costs. I > > don't understand why a change in semantics is regarded > > as more backwards compatible than a change in the syntax ? > > Because internal semantic processing does not require communications between > devices. Thus, you can maintain interoperability. Its the "black box" > paradigm; you have a hard time changing the interface between components in > a system, but you can easily change the internal implementation and > processing logic. > > That aside, the motivation for doing this oddball combination was to try and > preserve a "fundamental invariant" of SIP, which was that the request URI > should always refer to an entity that the request is actually addressed to. > If the UAS simply uses the Record-Routes as is for the Route header, this > won't be true. The result is a certain amount of brittleness. > > Now, I'm going to open a huge can of worms here. > > First, it seems I am in the minority of folks who think this approach > (mixing the RR and From/Contact) is sensible. I'm willing to entertain the > notion that preservation of a protocol invariant is less important than real > protocol operational problems. Since the maintenance of this invariant is > causing problems with spirals, perhaps it is not worth the pain, and we > should return to the original notion of just using the list in the order you > got it. > > Now, to make things more complex, we have a slight problem that > record-routing has troubles when the request URI in the incoming request is > not a SIP URL. Thats because, as you may recall, the RR process in a proxy > is to COPY the request URI into the RR, and then modify the maddr and port. > Now, maddr and port are SIP URL parameters. There are no such things for the > tel URL, for example. Thus, record routing a request with a tel URL is a bit > problematic. You basically need to convert it to a SIP URL first, or do > something else. Converting everything to SIP URLs may not always be possible > down the road. One can make the argument, and I would agree with it, that > the IP address and port of the proxy are not URI parameters, but > record-route header parameters. We did the hack of putting them in the URI > maddr and port since this is backwards compatible. > > So, perhaps we should consider defining address and port record-route > parameters. These would only be set when the request URI contained a non-SIP > URL. Proxies would use these parameters if present for routing instead of > the maddr and port in the URL. > > COmments? (I'm sure there are). > > -Jonathan R. > > > > > I would have prefered to add a port number in the > > maddr parameter because that's where I beleave it belongs. > > > > The second solution is to make it possible for a server > > to add it's own parameter in RECORD-ROUTE and then get > > it back in the REQUEST. Today a UAS only supposed to > > copy maddr and port value from RECORD-ROUTE to ROUTE. > > If all parameters was copied instead it would be possible > > for a server to add anything it likes in RECORD-ROUTE > > and get it back again. I beleave this kind of solution > > have been discussed for states ? > > > > /Bertil > > > > Bertil Engelholm wrote: > > > > > > Hi again, > > > > > > I'm sorry to bring this up again but I just can't get things > > > to work in the correct way. I have read through the old threads > > > regarding this matter and still don't understand how it is > > > suppose to work. > > > > > > It's this example again : > > > > > > --------- -------- -------- > > > | a@c1 | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> | | > > > --------- (contact a@c1) | | | | > > > | p1 | | p2 | > > > --------- | | | | > > > | b@c2 | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- | | > > > --------- -------- -------- > > > > > > If P1 is stateful it might allocate one "call" state machine for > > > each path the "call" takes in P1 (s1 and s2 in the picture). > > > These two state machines are identified by the REQUEST-URI > > > that came in the two INVITEs since that's the only thing that > > > differs the two from each other. (topmost VIA also differs, > > > more about that later) > > > > > > P1 will now include the REQUEST-URI in the branch value it > > > generates so that the responses can be directed to the right > > > state machine when they arrive. And when the ACK is sent the > > > original REQUEST-URI from ROUTE is used. So no problems here. > > > > > > The problem I have is when b@C2 sends a new request (eg. BYE). > > > According to the specification b should/must/may (or whatever) > > > overwrite the REQUEST-URI in the ROUTE headers using the > > > REQUEST-URI from CONTACT or FROM. > > > > > > So how should P1 now be able to differ the two (BYE) requests > > > from each other ? The Original REQUEST-URI was the only thing > > > that P1 had to identify the two state machines. > > > > > > When reading the old threads regarding this matter I saw > > > something about using topmost VIA in some way, but how ? > > > > > > By using the topmost VIA you can see that they are two different > > > requests but how do you identify which state machine should receive > > > the first request. (Someone might argue that it doesn't > > matter but if > > > P1 controls a firewall it DO matter. Maybe not for BYE but for a > > > RE-INVITE it matters). > > > > > > -- > > > Bertil Engelholm > > > AXE Research and Development voice : +46 8 727 3499 > > > SIP Security Fax : +46 8 647 8276 > > > S-126 25 Stockholm Sweden E-mail: > > > Bertil.Engelholm@uab.ericsson.se > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Bertil Engelholm > > AXE Research and Development voice : +46 8 727 3499 > > SIP Security Fax : +46 8 647 8276 > > S-126 25 Stockholm Sweden E-mail: > > Bertil.Engelholm@uab.ericsson.se > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 13:42:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04669 for ; Fri, 3 Nov 2000 13:42:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5FEF544337; Fri, 3 Nov 2000 12:42:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8EF7A44336 for ; Fri, 3 Nov 2000 12:41:09 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA19015; Fri, 3 Nov 2000 13:43:14 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YMP3>; Fri, 3 Nov 2000 13:36:44 -0500 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , Jonathan Rosenberg Cc: "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: RE: [SIP] Identification problem MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 13:36:36 -0500 > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Friday, November 03, 2000 1:06 PM > To: Jonathan Rosenberg > Cc: 'Bertil Engelholm'; SIP@lists.bell-labs.com > Subject: Re: [SIP] Identification problem > > > Aplogies for a rushed post but I thought we had this > covered already with the bis-02 introduction of global > unique via branch param. > > http://lists.bell-labs.com/pipermail/sip/2000q3/002635.html > > Am I missing the problem? The other RR suggestions are > certainly interesting ;) The problem is that the unique via branch param allows you to *differentiate* between each request, but there is no easy way to know that a request corresponds to a specific state machine. Thats because (1) the proxy immediately before and/or after P1 may not actually record-route, so the branch param in the original INVITE could be totally different from the one in the re-INVITE or BYE, and (2) proxy P1 has no way to know what the branch param for requests in the REVERSE direction will look like after the original INVITE. -Jonathan R. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] > > > Sent: Friday, November 03, 2000 10:54 AM > > > To: SIP@lists.bell-labs.com > > > Subject: [SIP] Identification problem > > > > > > > > > Hi, > > > > > > Sofar noone have responded to the problem below so this > > > third time I send it I try a new subject. I was hoping > > > that some SIP responsible people would come up with a > > > solution to the problem or atleast say if it is regarded > > > as a problem or not. > > > > Well, back in the good old days, the SIP list generated > just a few messages > > a day. I used to be able to respond almost immediately to > every question. > > Now, as we approach the average of 30 messages per day, it > is impossible for > > me, and many of the other SIP experts, to respond to every > question on the > > list. > > > > Anyway, to answer your question, I can think of a few additional > > possibiltiies: > > > > 1. P1 use a different IP address (i.e., different maddr) as > the request > > cycles through each time. This requires detection of the spiral and > > selection of a different address each time. This can be > done statelessly, > > since the previous maddr inserted will appear somewhere in > the Record-Route > > list when the request arrives again. This has the drawback > of requiring a > > server to be configured with some number of IP addresses. > > > > 2. The difference between the requests coming to P1 the > first time and > > second time is not just the top Via, but also the contents > of the Route > > header. What you can do is this: when the response to the > initial INVITE > > comes, the response carries the complete RR trace. You > should be able to > > infer from the request and the response what the Route > header set will look > > like by the time the messages reach P1, and this will be > different for both > > times the request arrives. > > > > 3. As Sean has pointed out, the State header is another > possibility. There > > is the unfortunate problem that this won't work if both UAs > don't support > > the State header, so you pretty much need a non-State based > solution anyway. > > > > Note that according to the spec now, the UAS does copy ONLY > the maddr and > > port from the RR header; everything else comes from the > Contact/From. > > > > > The first solution is to remove the text where it says > > > that a UA should fill all Routes with values from > > > CONTACT or FROM. Instead the original addresses should > > > be kept. Personally I find it strange when you combine > > > addresses (from CONTACT/FROM) with a port number from > > > RECORD-ROUTE. This means that the total address now is > > > completely useless. It looks to me that you try to > > > avoid syntax changes in the protocol at all costs. I > > > don't understand why a change in semantics is regarded > > > as more backwards compatible than a change in the syntax ? > > > > Because internal semantic processing does not require > communications between > > devices. Thus, you can maintain interoperability. Its the > "black box" > > paradigm; you have a hard time changing the interface > between components in > > a system, but you can easily change the internal implementation and > > processing logic. > > > > That aside, the motivation for doing this oddball > combination was to try and > > preserve a "fundamental invariant" of SIP, which was that > the request URI > > should always refer to an entity that the request is > actually addressed to. > > If the UAS simply uses the Record-Routes as is for the > Route header, this > > won't be true. The result is a certain amount of brittleness. > > > > Now, I'm going to open a huge can of worms here. > > > > First, it seems I am in the minority of folks who think > this approach > > (mixing the RR and From/Contact) is sensible. I'm willing > to entertain the > > notion that preservation of a protocol invariant is less > important than real > > protocol operational problems. Since the maintenance of > this invariant is > > causing problems with spirals, perhaps it is not worth the > pain, and we > > should return to the original notion of just using the list > in the order you > > got it. > > > > Now, to make things more complex, we have a slight problem that > > record-routing has troubles when the request URI in the > incoming request is > > not a SIP URL. Thats because, as you may recall, the RR > process in a proxy > > is to COPY the request URI into the RR, and then modify the > maddr and port. > > Now, maddr and port are SIP URL parameters. There are no > such things for the > > tel URL, for example. Thus, record routing a request with a > tel URL is a bit > > problematic. You basically need to convert it to a SIP URL > first, or do > > something else. Converting everything to SIP URLs may not > always be possible > > down the road. One can make the argument, and I would agree > with it, that > > the IP address and port of the proxy are not URI parameters, but > > record-route header parameters. We did the hack of putting > them in the URI > > maddr and port since this is backwards compatible. > > > > So, perhaps we should consider defining address and port > record-route > > parameters. These would only be set when the request URI > contained a non-SIP > > URL. Proxies would use these parameters if present for > routing instead of > > the maddr and port in the URL. > > > > COmments? (I'm sure there are). > > > > -Jonathan R. > > > > > > > > I would have prefered to add a port number in the > > > maddr parameter because that's where I beleave it belongs. > > > > > > The second solution is to make it possible for a server > > > to add it's own parameter in RECORD-ROUTE and then get > > > it back in the REQUEST. Today a UAS only supposed to > > > copy maddr and port value from RECORD-ROUTE to ROUTE. > > > If all parameters was copied instead it would be possible > > > for a server to add anything it likes in RECORD-ROUTE > > > and get it back again. I beleave this kind of solution > > > have been discussed for states ? > > > > > > /Bertil > > > > > > Bertil Engelholm wrote: > > > > > > > > Hi again, > > > > > > > > I'm sorry to bring this up again but I just can't get things > > > > to work in the correct way. I have read through the old threads > > > > regarding this matter and still don't understand how it is > > > > suppose to work. > > > > > > > > It's this example again : > > > > > > > > --------- -------- -------- > > > > | a@c1 | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> | | > > > > --------- (contact a@c1) | | | | > > > > | p1 | | p2 | > > > > --------- | | | | > > > > | b@c2 | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- | | > > > > --------- -------- -------- > > > > > > > > If P1 is stateful it might allocate one "call" state machine for > > > > each path the "call" takes in P1 (s1 and s2 in the picture). > > > > These two state machines are identified by the REQUEST-URI > > > > that came in the two INVITEs since that's the only thing that > > > > differs the two from each other. (topmost VIA also differs, > > > > more about that later) > > > > > > > > P1 will now include the REQUEST-URI in the branch value it > > > > generates so that the responses can be directed to the right > > > > state machine when they arrive. And when the ACK is sent the > > > > original REQUEST-URI from ROUTE is used. So no problems here. > > > > > > > > The problem I have is when b@C2 sends a new request (eg. BYE). > > > > According to the specification b should/must/may (or whatever) > > > > overwrite the REQUEST-URI in the ROUTE headers using the > > > > REQUEST-URI from CONTACT or FROM. > > > > > > > > So how should P1 now be able to differ the two (BYE) requests > > > > from each other ? The Original REQUEST-URI was the only thing > > > > that P1 had to identify the two state machines. > > > > > > > > When reading the old threads regarding this matter I saw > > > > something about using topmost VIA in some way, but how ? > > > > > > > > By using the topmost VIA you can see that they are two different > > > > requests but how do you identify which state machine > should receive > > > > the first request. (Someone might argue that it doesn't > > > matter but if > > > > P1 controls a firewall it DO matter. Maybe not for BYE but for a > > > > RE-INVITE it matters). > > > > > > > > -- > > > > Bertil Engelholm > > > > AXE Research and Development voice : +46 8 727 3499 > > > > SIP Security Fax : +46 8 647 8276 > > > > S-126 25 Stockholm Sweden E-mail: > > > > Bertil.Engelholm@uab.ericsson.se > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > -- > > > Bertil Engelholm > > > AXE Research and Development voice : +46 8 727 3499 > > > SIP Security Fax : +46 8 647 8276 > > > S-126 25 Stockholm Sweden E-mail: > > > Bertil.Engelholm@uab.ericsson.se > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > --- > > 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 > --- 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 Nov 3 13:46: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 NAA06227 for ; Fri, 3 Nov 2000 13:46:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EF4144337; Fri, 3 Nov 2000 12:46:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 248A444336 for ; Fri, 3 Nov 2000 12:45:51 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA19039; Fri, 3 Nov 2000 13:45:42 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA10742; Fri, 3 Nov 2000 13:45:43 -0500 (EST) Message-ID: <3A0332F5.9AA1DBA5@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] IANA SIP header registration References: <3A01C8D6.8906245C@cs.columbia.edu> <3A026AD3.70E41EC@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 03 Nov 2000 13:49:41 -0800 Content-Transfer-Encoding: 7bit The IANA registration simply registers existing formats and makes no statement as to whether compact forms are good, bad or indifferent. I agree that anything but single-letter abbreviations are useless and that those should be reserved to standards-track documents. Sean Olson wrote: > > Does this mean open season on compact forms? I really hope not. > In fact, I wish they would go away altogether. I don't want to re-open > this debate, but I would like to dam the flood of new compact forms. > > Am I the only one who feels this way? > /sean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 13:48: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 NAA07254 for ; Fri, 3 Nov 2000 13:48:37 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A95004435B; Fri, 3 Nov 2000 12:47:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id A19F644336 for ; Fri, 3 Nov 2000 12:46:47 -0500 (EST) 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 NAA19100 for ; Fri, 3 Nov 2000 13:46:37 -0500 (EST) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id NAA17783; Fri, 3 Nov 2000 13:46:37 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14851.2061.116391.77694@ind.cs.columbia.edu> To: sip@lists.bell-labs.com X-Mailer: VM 6.75 under Emacs 19.34.1 Subject: [SIP] Pre-loaded Route headers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 13:46:37 -0500 (EST) Content-Transfer-Encoding: 7bit I've been pondering details of the concept of "pre-loaded" Route headers -- Route headers that go in the initial transaction of a call, used to direct a call to go through an outbound proxy server. My question is, if you pre-load a Route header into an initial INVITE, do those Route headers have to persist for the rest of the call? Or do subsequent transactions just build their Route headers based on the Record-Routes that were inserted in that first transaction? I think it would have to be the latter, since the destination UAS doesn't see any of the pre-loaded Route headers. The UAS is going to all its routing based on those initial Record-Routes -- all the pre-loaded Routes are stripped by the time the request gets to the UAS. I was going to suggest that if you get a request with your own Route header in it you be required to insert yourself as a Record-Route -- until I remembered that you don't see Route headers for yourself. (This causes a lot of headaches, it seems.) The problem is that this seems to be asymmetric with how Route headers persist *after* the first transaction -- 2543bis says they remain even if subsequent transactions don't put Record-Routes in for them. This may be the correct behavior, but it should probably be called out explicitly. Thoughts? -- 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 Nov 3 14:12: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 OAA15211 for ; Fri, 3 Nov 2000 14:12:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E91CA44343; Fri, 3 Nov 2000 13:12:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by lists.bell-labs.com (Postfix) with ESMTP id 2161744336 for ; Fri, 3 Nov 2000 13:11:57 -0500 (EST) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id LAA22076; Fri, 3 Nov 2000 11:11:47 -0800 (PST) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 03 Nov 2000 19:11:46 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 11:11:45 -0800 Message-ID: From: "Agarwal, Aseem" To: "'SIP List'" Cc: "'Jonathan Rosenberg'" Subject: RE: [SIP] Sip- Message OPTION 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, 3 Nov 2000 10:19:48 -0800 Hi Jonathan, The draft (bis-2 section 4.2.3) says: "The response MAY contain a message body indicating the capabilities of the end system ..." This gives an idea that OPTIONS should be relevant only for a UAS, since only a UAS can respond with the capabilities of the logged in users. The example given in section 16.8, also seems to suggest the same. However, theoretically, it is possible for a user to register his media capabilities as well in the REGISTER message with the Registrar. But I see this as a more dynamic thing which can potentially change from a call to call. So, what is the usage of supporting OPTIONS at a Registrar server ? Kindly clarify. -regards, aseem -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, November 02, 2000 11:39 PM To: 'Thys Nel'; 'Billy Biggs'; archow@hss.hns.com Cc: 'Sandeep Sahai'; 'SIP List' Subject: RE: [SIP] Sip- Message OPTION All servers (UAS, registrar) should answer a OPTIONS with a 200 OK with the following headers added to the response: Allow, listing the supported methods, Accept, listing the support MIME types, and Supported, listing the supported extensions. A UAS could also insert SDP listing its codecs. How such SDP is formatted has never been defined, and to my knowledge, no one is yet doing this. We'll define something in bis. As an example for a registrar response to OPTIONS: SIP/2.0 200 OK From: sip:querier@company.com To: sip:registardomain.com;tag=9378asd0asd7asd Call-ID: a90sda08shd@1.2.3.4 CSeq: 1 REGISTER Via: SIP/2.0/UDP host.company.com Accept: application/cpl+xml Allow: OPTIONS, REGISTER, CANCEL Supported: pref Content-Length: 0 This registar supports uploads of CPL, and also the caller preferences extension. -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: Thys Nel [mailto:thys@parsec.co.za] > Sent: Thursday, November 02, 2000 1:48 AM > To: 'Billy Biggs'; archow@hss.hns.com > Cc: 'Sandeep Sahai'; 'SIP List' > Subject: RE: [SIP] Sip- Message OPTION > > > Does anyone have examples of messages flows with OPTIONS > processed by a > registrar server? The only example in the RFC is between 2 > user agents, but > the RFC states that a registrar must also support it. I can't > seem to find > any description of when a registrar should respond to an > OPTIONS request. > > Thys > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Billy Biggs > > Sent: 02 November 2000 8:17 > > To: archow@hss.hns.com > > Cc: Sandeep Sahai; SIP List > > Subject: Re: [SIP] Sip- Message OPTION > > > > > > Note that this should be cleaned up. There is no Via or > CSeq in the > > response, the CSeq in the request starts at 1, the From has > > no tag, and there > > is no Content-Length. > > > > > C->S: OPTIONS sip:bob@example.com SIP/2.0 > > > Via: SIP/2.0/UDP cat.wonderland.com > > > From: Alice > > > To: Bob > > > Call-ID: 6378@cat.wonderland.com > > > CSeq: 1 OPTIONS > > > Accept: application/sdp > > > > > > S->C: SIP/2.0 200 OK > > > From: Alice > > > To: Bob ;tag=376364382 > > > Call-ID: 6378@cat.wonderland.com > > > Content-Length: 81 > > > Content-Type: application/sdp > > > > > > v=0 > > > o=alice 3149329138 3149329165 IN IP4 24.124.37.3 > > > s=Security problems > > > t=3149328650 0 > > > c=IN IP4 24.124.37.3 > > > m=audio 0 RTP/AVP 0 1 3 99 > > > a=rtpmap:0 PCMU/8000 > > > a=rtpmap:1 1016/8000 > > > a=rtpmap:3 GSM/8000 > > > a=rtpmap:99 SX7300/8000 > > > m=video 0 RTP/AVP 31 34 > > > a=rtpmap:31 H261/90000 > > > a=rtpmap:34 H263/90000 > > > > -- > > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 3 14:22: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 OAA17779 for ; Fri, 3 Nov 2000 14:22:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3360B44337; Fri, 3 Nov 2000 13:22:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by lists.bell-labs.com (Postfix) with ESMTP id ED34944336 for ; Fri, 3 Nov 2000 13:21:42 -0500 (EST) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id LAA24540; Fri, 3 Nov 2000 11:21:33 -0800 (PST) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 03 Nov 2000 19:21:27 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 11:21:26 -0800 Message-ID: From: "Singh, Manish" To: "'Jonathan Rosenberg'" , "Singh, Manish" , "'Robin Escolme'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 10:30:02 -0800 Hi : Thanks for the response. Another concern, section 5 states - "Session expiration are mostly of interest to call stateful proxy servers. However, a stateful proxy server MAY also follow the rules described here" Shouldn't it be mandated by the draft that, if a stateful proxy (transaction stateful case) server is starting a Session Timer, it MUST insert a "Record-Route" header in the Invite, prior to proxying it. Since, the procedure is symmetric, i.e. UAS can send a Re-Invite and become the master, to avoid such proxies being missed out and later timing out, it MUST be on the path. Also, is there any example when a transaction stateful only proxy would like to start a session timer? -Regards, Manish Singh > > Hi, > > Sectoin 4, UAC behavior states : > > "Note that it is possible that the calling UA is generating > refreshes, and then it receives a re-INVITE. After following > the rules for UAS described below, the calling UA now determines > it is not supposed to generate refreshes..........." > > Is their a specific reason for allowing the master switchover > for generating the re-INVITES? After the initial negotation, if > the UAC was responsible for generating re-INVITES, why would UAS > in the middle of a session like to take control? The idea was just to make the whole process stateless, so that processing of a re-INVITE is absolutely the same as processing the initial INVITE. As a result of this choice, the roles will change over on re-INVITEs depending on what level of support each side has. If each side both supports session timer, the user sending the re-INVITE will become the one performing refreshes if the re-invite completes successfully. The stateless operation is needed, for example, to recover from crash-reboot cycles. I think this actually makes the implementation simpler, not more complex. > > Can we add an Example flow for this scenario in section 8 of the > draft. I will add text explaining the above, and also an example flow. -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 Nov 3 14:46: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 OAA25117 for ; Fri, 3 Nov 2000 14:46:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57C3C44364; Fri, 3 Nov 2000 13:43:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 2461744363 for ; Fri, 3 Nov 2000 13:42:51 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Fri, 3 Nov 2000 13:38:14 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 3 Nov 2000 13:42:21 -0600 Message-ID: <2E532B03F035D3119AF40000F80932C37B6F1C@crchy28d.us.nortel.com> From: "Shantala Manchenahally" To: "'Jonathan Lennox'" , sip@lists.bell-labs.com Subject: RE: [SIP] Pre-loaded Route headers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C045CE.2D22D190" 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: Fri, 3 Nov 2000 13:42:18 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C045CE.2D22D190 Content-Type: text/plain; charset="iso-8859-1" Hi, Just a few thoughts on the matter.. I agree that a Record is stripped before it gets to the Proxy. However if a proxy see's a Route Header (specifying the next hop)in the initial request, it can decide to add itself to the Record-Route. If every Proxy along the path obeys this rule then the pre-loaded route will be preserved for all subsequent transactions. This wouldn't work for the cases where the pre-loaded Route doesn't specify all the hops between the UAC and the UAS. So a Proxy may not see a Route header at all, even though the initial message did contain a Route header. So I would think that a pre-loaded Route can effectively be applied for that transaction alone. Shantala. -----Original Message----- From: Jonathan Lennox [mailto:lennox@cs.columbia.edu] Sent: Friday, November 03, 2000 12:47 PM To: sip@lists.bell-labs.com Subject: [SIP] Pre-loaded Route headers I've been pondering details of the concept of "pre-loaded" Route headers -- Route headers that go in the initial transaction of a call, used to direct a call to go through an outbound proxy server. My question is, if you pre-load a Route header into an initial INVITE, do those Route headers have to persist for the rest of the call? Or do subsequent transactions just build their Route headers based on the Record-Routes that were inserted in that first transaction? I think it would have to be the latter, since the destination UAS doesn't see any of the pre-loaded Route headers. The UAS is going to all its routing based on those initial Record-Routes -- all the pre-loaded Routes are stripped by the time the request gets to the UAS. I was going to suggest that if you get a request with your own Route header in it you be required to insert yourself as a Record-Route -- until I remembered that you don't see Route headers for yourself. (This causes a lot of headaches, it seems.) The problem is that this seems to be asymmetric with how Route headers persist *after* the first transaction -- 2543bis says they remain even if subsequent transactions don't put Record-Routes in for them. This may be the correct behavior, but it should probably be called out explicitly. Thoughts? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C045CE.2D22D190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Pre-loaded Route headers

Hi,

Just a few thoughts on the matter..

I agree that a Record is stripped before it gets to = the Proxy. However if a proxy see's a Route Header (specifying the next = hop)in the initial request, it can decide to add itself to the = Record-Route. If every Proxy along the path

obeys this rule then the pre-loaded route will be = preserved for all subsequent transactions.

This wouldn't work for the cases where the pre-loaded = Route doesn't specify all the hops
between the UAC and the UAS. So a Proxy may not see = a Route header at all, even though the initial message did contain a = Route header.

So I would think that a pre-loaded Route can = effectively be applied for that transaction alone.

Shantala.

-----Original Message-----
From: Jonathan Lennox [mailto:lennox@cs.columbia.edu= ]
Sent: Friday, November 03, 2000 12:47 PM
To: sip@lists.bell-labs.com
Subject: [SIP] Pre-loaded Route headers


I've been pondering details of the concept of = "pre-loaded" Route headers --
Route headers that go in the initial transaction of = a call, used to direct a
call to go through an outbound proxy server.

My question is, if you pre-load a Route header into = an initial INVITE, do
those Route headers have to persist for the rest of = the call?  Or do
subsequent transactions just build their Route = headers based on the
Record-Routes that were inserted in that first = transaction?

I think it would have to be the latter, since the = destination UAS doesn't
see any of the pre-loaded Route headers.  The = UAS is going to all its
routing based on those initial Record-Routes -- all = the pre-loaded Routes
are stripped by the time the request gets to the = UAS.

I was going to suggest that if you get a request with = your own Route header
in it you be required to insert yourself as a = Record-Route -- until I
remembered that you don't see Route headers for = yourself.  (This causes a
lot of headaches, it seems.)

The problem is that this seems to be asymmetric with = how Route headers
persist *after* the first transaction -- 2543bis = says they remain even if
subsequent transactions don't put Record-Routes in = for them.  This may be
the correct behavior, but it should probably be = called out explicitly.

Thoughts?

--
Jonathan Lennox
lennox@cs.columbia.edu

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

------_=_NextPart_001_01C045CE.2D22D190-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 16:04:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22393 for ; Fri, 3 Nov 2000 16:04:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F29D844337; Fri, 3 Nov 2000 15:04:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id 5C24344336 for ; Fri, 3 Nov 2000 15:03:21 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 0EE5F4CE8A for ; Fri, 3 Nov 2000 16:03:12 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA18329 for ; Fri, 3 Nov 2000 16:03:11 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id QAA67948 for sip@lists.bell-labs.com; Fri, 3 Nov 2000 16:01:41 -0500 (EST) Message-Id: <200011032101.QAA67948@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: [SIP] Re: Pre-loaded Route headers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 16:01:41 -0500 (EST) I believe there may be a problem with Pre-loaded Route headers and stateless proxies, but it not a difficult one to solve. But there are side-affects that are not nice. An initial INVITE is normally the one that accumulates the Record-Route values; then they are stored at the UAS and converted into a Route header for UAS->UAC transactions, and echoed back to the UAC in the 200-OK so the UAC converts them into a Route header for UAC->UAS transactions. A mid-call INVITE (or any other message) contains the Route header value, but doesn't need to accumulate Record-Routes again. But a stateless proxy can't really tell the difference between an initial INVITE for a new session (one in which it should add itself to the Record-Route) and a mid-call INVITE for an existing session (in which it doesn't need to add itself). So it has two choices: 1) always add itself to a Record-Route, or 2) note there is a Route header and assume therefore it is a mid-call message and do nothing. Keying on the existence of a Route header to indicate a mid-call message isn't explicitely disallowed by the spec (unless I missed it somewhere), but it would work just fine - until a UAC tried to use a pre-loaded Route header. Then the proxy wouldn't get itself into the Record-Route when it should. So the solution is to have the proxy insert itself into the Record-Route header *independent of whether it is an initial INVITE or a mid-call INVITE*. Unfortunately there is a backward compatibility problem here - a proxy that doesn't know to do this for a mid-call message will be dropped from future messages. If even one proxy along the path inserts a Record-Route header on the mid-call message, the UAS and UAC will trigger their Route re-calculation. (Presumably if none of the proxies did the Record-Route for a mid-call message, the UAC and UAS would act like currently, and keep the Route from the initial INVITE). Is this just a theoretical problem, or does it break real proxy implementations? Bill Marshall wtm@research.att.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 18:23:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27304 for ; Fri, 3 Nov 2000 18:23:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C13544337; Fri, 3 Nov 2000 17:23:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sargasso.cse.msu.edu (sargasso.cse.msu.edu [35.9.20.10]) by lists.bell-labs.com (Postfix) with ESMTP id DC20844336 for ; Fri, 3 Nov 2000 17:22:44 -0500 (EST) Received: from arctic.cse.msu.edu (arctic.cse.msu.edu [35.9.20.20]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with ESMTP id SAA13523 for ; Fri, 3 Nov 2000 18:22:37 -0500 (EST) From: Tajindrapal Singh Received: (from singhtaj@localhost) by arctic.cse.msu.edu (8.8.8/8.8.8) id SAA03901 for sip@lists.bell-labs.com; Fri, 3 Nov 2000 18:22:37 -0500 (EST) Message-Id: <200011032322.SAA03901@arctic.cse.msu.edu> To: sip@lists.bell-labs.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Help with installation of sipd Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 3 Nov 2000 18:22:37 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, We are trying to install sipd (columbia release) on a linux box. But, before compiling sipd server, do we need to install the LDAP (Umich distribution)? If so then I guess we need root access for installation of LDAP?? In the README.build of sipd there is an example for configuring as follows: ./configure --with-db=/proj/irt-gc4/cinema/sun5 \ --with-ldap=/proj/irt-gc4/cinema/sun5 Now, we are not sure as to what should be in the sun5 directory? Should there be the sources for LDAP and berkely db? OR Is it the executables that needs to be present in this directory? Any help and suggestions will be greatly appreciated. Thanks T.Singh _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 18:39: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 SAA00867 for ; Fri, 3 Nov 2000 18:39:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A6E0D44337; Fri, 3 Nov 2000 17:39:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 524FA44336 for ; Fri, 3 Nov 2000 17:38:58 -0500 (EST) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G3H2KS00.FKJ for ; Fri, 3 Nov 2000 15:29:16 -0800 Message-ID: <3A034C87.EA59D978@vovida.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: SIP development list Content-Type: multipart/alternative; boundary="------------FD146D194749A162FDB118BB" Subject: [SIP] putting media on hold Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 03 Nov 2000 15:38:47 -0800 --------------FD146D194749A162FDB118BB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, according to section B. 6 in a new draft it is possible to put the other party "on hold", that is to ask it temporarily stop sending media, by sending re-INVITE with the destina- tion addresses (c= lines) set to 0. What should we expect in 200 OK ? Should it be (upon acception of re-INVITE) the regular SDP with valid ports and destination addresses, since it stops sending, but still continue receiving ? Thanx. -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.com --------------FD146D194749A162FDB118BB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,
    according to section B. 6 in a new draft it is possible to put the other party "on hold",
that is to ask it temporarily stop sending media, by sending re-INVITE with the destina-
tion addresses (c= lines) set to 0.
What should we expect in 200 OK ? Should it be (upon acception of re-INVITE) the
regular SDP with valid ports and destination addresses, since it stops sending, but
still continue receiving ?

Thanx. 

-- 
Vladislav Zubarev        mailto:vladis@vovida.com
Software Engineer   
Vovida Networks, Inc.    http://www.vovida.com
  --------------FD146D194749A162FDB118BB-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 18:52:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03695 for ; Fri, 3 Nov 2000 18:52:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94C3944337; Fri, 3 Nov 2000 17:52:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id 1D49444336 for ; Fri, 3 Nov 2000 17:51:20 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA20313 for ; Fri, 3 Nov 2000 16:51:13 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA24356 for ; Fri, 3 Nov 2000 16:51:13 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 3 Nov 2000 17:49:51 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED85F7@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: SIP@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Media to send Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 3 Nov 2000 17:49:51 -0600 2543bis 4.2.1 INVITE: "The INVITE method indicates that the user or service is being invited to participate in a session. The message body MAY contain a description of the session to which the callee is being invited. For two-party calls, the caller indicates the type of media it is able to receive and possibly the media it is willing to send as well as their parameters such as network destination. A success response MUST indicate in its message body which media the callee wishes to receive and MAY indicate the media the callee is going to send." How does a UA indicate (in case it wishes) the media it is going to send? Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 3 20:27: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 UAA24243 for ; Fri, 3 Nov 2000 20:27:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0B2E44337; Fri, 3 Nov 2000 19:27:06 -0500 (EST) 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 CCD2244336 for ; Fri, 3 Nov 2000 19:26:52 -0500 (EST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id BAA17180; Sat, 4 Nov 2000 01:27:46 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sat, 04 Nov 2000 01:26:30 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 17:26:28 -0800 Message-ID: From: "Singh, Manish" To: "'William Marshall'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: Pre-loaded Route headers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 3 Nov 2000 17:26:28 -0800 Hi : If any proxy inserts a Record-Route header in mid-call message, how will UAS and UAC re-calculate the Route header? A -INV-> P1 -INV(RR:P1)-> P2 -INV(RR:P1)-> B In this case P1 decides to add Record-Route header in the intial Invite, however P2 doesn't. Now, if 'A' sends a re-Invite, the Route header mandates only P1 to be in the path. However, if P1 proxies this re-Invite to another proxy P2' this time (depending on SRV records), and P2' policy is to add Record-Route in the mid-call message, when the re-Invite reaches 'B', how will it re-construct the correct Route header. To examplify, pls consider these secnarios - 1. It is possible, that after P2, there is another proxy P3, and P3 in the initial Invite had also added Record-Route, so the Route at 'B' was P3, P1. With P2', in the Re-Invite case, it should then be P3, P2', P1. A -> P1 -> P2 -> P3 -> B (Original Invite Path) A -> P1 -> P2'-> P3 -> B (Re-Invite Path) 2. If P3 in the initial Invite was prior to P2, then the initial Route at 'B' was still P3, P1. However, after re-Invite it should be P2', P3, P1. A -> P1 -> P3 -> P2 -> B (Original Invite Path) A -> P1 -> P3 -> P2'-> B (Re-Invite Path) So, how will UAS re-calculate the Route header? Is there something I am missing? Comments? Thanks, Manish Singh -----Original Message----- From: William Marshall [mailto:wtm@research.att.com] Sent: Friday, November 03, 2000 1:02 PM To: sip@lists.bell-labs.com Subject: [SIP] Re: Pre-loaded Route headers I believe there may be a problem with Pre-loaded Route headers and stateless proxies, but it not a difficult one to solve. But there are side-affects that are not nice. An initial INVITE is normally the one that accumulates the Record-Route values; then they are stored at the UAS and converted into a Route header for UAS->UAC transactions, and echoed back to the UAC in the 200-OK so the UAC converts them into a Route header for UAC->UAS transactions. A mid-call INVITE (or any other message) contains the Route header value, but doesn't need to accumulate Record-Routes again. But a stateless proxy can't really tell the difference between an initial INVITE for a new session (one in which it should add itself to the Record-Route) and a mid-call INVITE for an existing session (in which it doesn't need to add itself). So it has two choices: 1) always add itself to a Record-Route, or 2) note there is a Route header and assume therefore it is a mid-call message and do nothing. Keying on the existence of a Route header to indicate a mid-call message isn't explicitely disallowed by the spec (unless I missed it somewhere), but it would work just fine - until a UAC tried to use a pre-loaded Route header. Then the proxy wouldn't get itself into the Record-Route when it should. So the solution is to have the proxy insert itself into the Record-Route header *independent of whether it is an initial INVITE or a mid-call INVITE*. Unfortunately there is a backward compatibility problem here - a proxy that doesn't know to do this for a mid-call message will be dropped from future messages. If even one proxy along the path inserts a Record-Route header on the mid-call message, the UAS and UAC will trigger their Route re-calculation. (Presumably if none of the proxies did the Record-Route for a mid-call message, the UAC and UAS would act like currently, and keep the Route from the initial INVITE). Is this just a theoretical problem, or does it break real proxy implementations? Bill Marshall wtm@research.att.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 Sat Nov 4 04:43:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26711 for ; Sat, 4 Nov 2000 04:43:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E32044337; Sat, 4 Nov 2000 03:43:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by lists.bell-labs.com (Postfix) with ESMTP id A529644336 for ; Sat, 4 Nov 2000 03:41:46 -0500 (EST) Received: from rts.nio1.loniis (rts.loniis.ru [195.201.37.111]) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id eA49fXH02186 for ; Sat, 4 Nov 2000 12:41:33 +0300 (MSK) Received: from Vova (vova.rts.nio1.loniis [192.168.100.180]) by rts.nio1.loniis (Postfix) with SMTP id 373D3229 for ; Sat, 4 Nov 2000 12:47:23 +0300 (MSK) Message-ID: <000f01c04643$7fb9a580$b464a8c0@rts.nio1.loniis> From: "Samorezov Vladimir" To: Subject: [SIP] failure of proxy MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C0465C.A478F560" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 4 Nov 2000 12:42:07 +0300 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C0465C.A478F560 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, all! Could you help me in my SIPs study? If proxy forwards a SIP request, it add Via header with its address. = This ensures responses take the same path as the requests. OK! If one proxy along the path is failure, what upstream proxy must do to = route responses? =20 Thank you! Samorezov Vladimir. ------=_NextPart_000_000C_01C0465C.A478F560 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi, all!
Could you help me in my SIPs=20 study?
If proxy forwards a SIP = request, it add=20 Via header with its address. This ensures responses = take the=20 same path as the requests. OK!
If one proxy along the path = is failure,=20 what upstream proxy must do to route responses?   =
 
Thank you!
Samorezov=20 Vladimir.
------=_NextPart_000_000C_01C0465C.A478F560-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 4 07: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 HAA23872 for ; Sat, 4 Nov 2000 07:41:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6169744339; Sat, 4 Nov 2000 06:41:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 2A5FA44336 for ; Sat, 4 Nov 2000 00:49:11 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id VAA14484; Fri, 3 Nov 2000 21:32:23 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 From: David Shrader To: Henning Schulzrinne Cc: SIP List Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [SIP] rfc2543bis comment/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: Sat, 04 Nov 2000 00:28:49 -0500 Content-Transfer-Encoding: 7bit Table 5 contains a note 2 regarding the Via field. It states that the UAS removes first Via header field. This seems to be in direct contradiction to the purpose of the Via field. When that proxy receives the response, if there is no Via field in it, then 1) it can't know that it is meant for it and 2) it wouldn't be able to identify the branch without the branch parameter. Am I missing something? What was meant by the note in Table 5? ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 4 16:00:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01149 for ; Sat, 4 Nov 2000 16:00:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 11C6244339; Sat, 4 Nov 2000 15:00:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1266F44337 for ; Sat, 4 Nov 2000 14:59:55 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA14557; Sat, 4 Nov 2000 15:59:36 -0500 (EST) Message-ID: <3A0478B9.A91A6A65@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: iana@iana.org Cc: Allison Mankin , Scott Bradner , sip@lists.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Additional registries for SIP (RFC 2543) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 04 Nov 2000 15:59:37 -0500 Content-Transfer-Encoding: 7bit IANA wrote: > > Dear Henning, > > We apologize for the delay. We have been in touch with the ADs and > IANA will set up this new registry. > > Would it be possible to get an initial file of values so that we can > set this up. It would also be helpful to have a small paragraph > of text for the beginning of the file. Will you be able to provide > this? The current list is at http://www.cs.columbia.edu/sip/headers.txt > > In your IANA considerations section, you will need to include the procedure > for deciding when and how a new one can be registered. A suggestion is SIP Header field names are registered with IANA. They do not require working group or working group chair review, but {\SHOULD} be documented in an RFC or Internet draft. Headers {\SHOULDNOT} use the \header{X-} prefix notation and {\MUSTNOT} duplicate the names of headers used by SMTP or HTTP unless the syntax is a compatible superset and the semantics are similar. Some common and widely used header fields {\MAY} be assigned one-letter compact forms (Section~\ref{sec:compact}). Compact forms can only be assigned after SIP working group review. In the absence of this working group, a designated expert. > > Let me know if you have any questions with the above. Thanks for your help. > > Thank you, > > Michelle Schipper > IANA Administrator -- 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 Nov 6 05:03: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 FAA13971 for ; Mon, 6 Nov 2000 05:03:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7765A4433A; Mon, 6 Nov 2000 04:03:12 -0500 (EST) 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 D303944337 for ; Mon, 6 Nov 2000 04:02:33 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 6 Nov 2000 10:02:28 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA16845; Mon, 6 Nov 2000 11:00:38 +0100 (BST) Message-ID: <3A068146.31045BE9@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: Re: [SIP] Identification 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 06 Nov 2000 10:00:38 +0000 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [snip] > Now, I'm going to open a huge can of worms here. > > First, it seems I am in the minority of folks who think this approach > (mixing the RR and From/Contact) is sensible. I'm willing to entertain the > notion that preservation of a protocol invariant is less important than real > protocol operational problems. Since the maintenance of this invariant is > causing problems with spirals, perhaps it is not worth the pain, and we > should return to the original notion of just using the list in the order you > got it. I don't like this. We should stick to the basic principal that Request URIs refer to the addressed entity. Breaking that would just create confusion. Though I do have a slight problem in that we already weaken the premise by allowing overloading of the port value within the hostport. > Now, to make things more complex, we have a slight problem that > record-routing has troubles when the request URI in the incoming request is > not a SIP URL. Thats because, as you may recall, the RR process in a proxy > is to COPY the request URI into the RR, and then modify the maddr and port. > Now, maddr and port are SIP URL parameters. There are no such things for the > tel URL, for example. Thus, record routing a request with a tel URL is a bit > problematic. You basically need to convert it to a SIP URL first, or do > something else. Converting everything to SIP URLs may not always be possible > down the road. One can make the argument, and I would agree with it, that > the IP address and port of the proxy are not URI parameters, but > record-route header parameters. We did the hack of putting them in the URI > maddr and port since this is backwards compatible. > > So, perhaps we should consider defining address and port record-route > parameters. These would only be set when the request URI contained a non-SIP > URL. Proxies would use these parameters if present for routing instead of > the maddr and port in the URL. There is a potential problem here and this looks like a reasonable solution. Pitty we can't extend it to all URLs. 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 Nov 6 05:16:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18042 for ; Mon, 6 Nov 2000 05:16:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C15B44433F; Mon, 6 Nov 2000 04:16:05 -0500 (EST) 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 DE18E44337 for ; Mon, 6 Nov 2000 04:15:46 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 6 Nov 2000 10:15:41 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA21797; Mon, 6 Nov 2000 11:14:08 +0100 (BST) Message-ID: <3A06846F.E2AE87EE@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: Re: [SIP] Identification 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 06 Nov 2000 10:14:07 +0000 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Am I missing the problem? The other RR suggestions are > > certainly interesting ;) > > The problem is that the unique via branch param allows you to > *differentiate* between each request, but there is no easy way to know that > a request corresponds to a specific state machine. Thats because (1) the > proxy immediately before and/or after P1 may not actually record-route, so > the branch param in the original INVITE could be totally different from the > one in the re-INVITE or BYE, and (2) proxy P1 has no way to know what the > branch param for requests in the REVERSE direction will look like after the > original INVITE. I agree there is this issue but is it really a problem for the spec? I saw this as just one of the additional challenges faced by a Proxy wishing to be call stateful. It isn't easy but I think it is already solvable without requiring further addition to the spec. If there is a neat solution that adds something more if everybody follows it then we should add it. If not we don't need more text. 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 Nov 6 07:57:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11309 for ; Mon, 6 Nov 2000 07:57:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 97CCC4433A; Mon, 6 Nov 2000 06:57:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 574B344338 for ; Mon, 6 Nov 2000 06:56:38 -0500 (EST) Received: from Hash (212.28.212.200 [212.28.212.200]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V797LWL3; Mon, 6 Nov 2000 13:51:57 +0100 From: "Hisham Khartabil" To: "Jonathan Lennox" , Subject: RE: [SIP] Pre-loaded Route headers Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <14851.2061.116391.77694@ind.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: Mon, 6 Nov 2000 14:57:52 +0200 Content-Transfer-Encoding: 7bit My questions are: 1. who would build this initial route header? It would have to be the user 2. how would this user know of the path? Regards, Hisham Hotsip -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Lennox Sent: Friday, 3 November 2000 8:47 PM To: sip@lists.bell-labs.com Subject: [SIP] Pre-loaded Route headers I've been pondering details of the concept of "pre-loaded" Route headers -- Route headers that go in the initial transaction of a call, used to direct a call to go through an outbound proxy server. My question is, if you pre-load a Route header into an initial INVITE, do those Route headers have to persist for the rest of the call? Or do subsequent transactions just build their Route headers based on the Record-Routes that were inserted in that first transaction? I think it would have to be the latter, since the destination UAS doesn't see any of the pre-loaded Route headers. The UAS is going to all its routing based on those initial Record-Routes -- all the pre-loaded Routes are stripped by the time the request gets to the UAS. I was going to suggest that if you get a request with your own Route header in it you be required to insert yourself as a Record-Route -- until I remembered that you don't see Route headers for yourself. (This causes a lot of headaches, it seems.) The problem is that this seems to be asymmetric with how Route headers persist *after* the first transaction -- 2543bis says they remain even if subsequent transactions don't put Record-Routes in for them. This may be the correct behavior, but it should probably be called out explicitly. Thoughts? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 6 08:48: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 IAA23685 for ; Mon, 6 Nov 2000 08:48:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 574B944338; Mon, 6 Nov 2000 07:48:06 -0500 (EST) 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 B6BCD44337 for ; Mon, 6 Nov 2000 07:47:38 -0500 (EST) 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 eA6DlWZ06383; Mon, 6 Nov 2000 14:47:32 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id eA6DlWn11708; Mon, 6 Nov 2000 14:47:32 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id OAA15347; Mon, 6 Nov 2000 14:47:31 +0100 (MET) Message-ID: <3A06B66E.7217C689@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Cc: Jonathan Rosenberg Subject: Re: [SIP] Identification problem References: <8tv8js$2fp$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 06 Nov 2000 14:47:26 +0100 Content-Transfer-Encoding: 7bit See comments below. /Bertil Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] > > Sent: Friday, November 03, 2000 10:54 AM > > To: SIP@lists.bell-labs.com > > Subject: [SIP] Identification problem > > > > > > Hi, > > > > Sofar noone have responded to the problem below so this > > third time I send it I try a new subject. I was hoping > > that some SIP responsible people would come up with a > > solution to the problem or atleast say if it is regarded > > as a problem or not. > > Well, back in the good old days, the SIP list generated just a few messages > a day. I used to be able to respond almost immediately to every question. > Now, as we approach the average of 30 messages per day, it is impossible for > me, and many of the other SIP experts, to respond to every question on the > list. > > Anyway, to answer your question, I can think of a few additional > possibiltiies: > > 1. P1 use a different IP address (i.e., different maddr) as the request > cycles through each time. This requires detection of the spiral and > selection of a different address each time. This can be done statelessly, > since the previous maddr inserted will appear somewhere in the Record-Route > list when the request arrives again. This has the drawback of requiring a > server to be configured with some number of IP addresses. This is a little bit to much of a hack solution for my taste. How many IP-addresses do you need ? How many times can you spirale through a proxy ? > > 2. The difference between the requests coming to P1 the first time and > second time is not just the top Via, but also the contents of the Route > header. What you can do is this: when the response to the initial INVITE > comes, the response carries the complete RR trace. You should be able to > infer from the request and the response what the Route header set will look > like by the time the messages reach P1, and this will be different for both > times the request arrives. This might be a possibly solution but only if it's totally forbidden for a proxy to jump off a route chain after some requests. Since you should add new record-route for every new request a proxy can technically remove himself from the list in the middle of a call or is this forbidden ?? > > 3. As Sean has pointed out, the State header is another possibility. There > is the unfortunate problem that this won't work if both UAs don't support > the State header, so you pretty much need a non-State based solution anyway. Isn't the State header a separate draft ? Can I require that all devices have implemented this draft. I would prefer a solution that is included in RFC2543. > > Note that according to the spec now, the UAS does copy ONLY the maddr and > port from the RR header; everything else comes from the Contact/From. > > > The first solution is to remove the text where it says > > that a UA should fill all Routes with values from > > CONTACT or FROM. Instead the original addresses should > > be kept. Personally I find it strange when you combine > > addresses (from CONTACT/FROM) with a port number from > > RECORD-ROUTE. This means that the total address now is > > completely useless. It looks to me that you try to > > avoid syntax changes in the protocol at all costs. I > > don't understand why a change in semantics is regarded > > as more backwards compatible than a change in the syntax ? > > Because internal semantic processing does not require communications between > devices. Thus, you can maintain interoperability. Its the "black box" > paradigm; you have a hard time changing the interface between components in > a system, but you can easily change the internal implementation and > processing logic. > > That aside, the motivation for doing this oddball combination was to try and > preserve a "fundamental invariant" of SIP, which was that the request URI > should always refer to an entity that the request is actually addressed to. > If the UAS simply uses the Record-Routes as is for the Route header, this > won't be true. The result is a certain amount of brittleness. > > Now, I'm going to open a huge can of worms here. > > First, it seems I am in the minority of folks who think this approach > (mixing the RR and From/Contact) is sensible. I'm willing to entertain the > notion that preservation of a protocol invariant is less important than real > protocol operational problems. Since the maintenance of this invariant is > causing problems with spirals, perhaps it is not worth the pain, and we > should return to the original notion of just using the list in the order you > got it. > > Now, to make things more complex, we have a slight problem that > record-routing has troubles when the request URI in the incoming request is > not a SIP URL. Thats because, as you may recall, the RR process in a proxy > is to COPY the request URI into the RR, and then modify the maddr and port. > Now, maddr and port are SIP URL parameters. There are no such things for the > tel URL, for example. Thus, record routing a request with a tel URL is a bit > problematic. You basically need to convert it to a SIP URL first, or do > something else. Converting everything to SIP URLs may not always be possible > down the road. One can make the argument, and I would agree with it, that > the IP address and port of the proxy are not URI parameters, but > record-route header parameters. We did the hack of putting them in the URI > maddr and port since this is backwards compatible. > > So, perhaps we should consider defining address and port record-route > parameters. These would only be set when the request URI contained a non-SIP > URL. Proxies would use these parameters if present for routing instead of > the maddr and port in the URL. > > COmments? (I'm sure there are). > > -Jonathan R. > > > > > I would have prefered to add a port number in the > > maddr parameter because that's where I beleave it belongs. > > > > The second solution is to make it possible for a server > > to add it's own parameter in RECORD-ROUTE and then get > > it back in the REQUEST. Today a UAS only supposed to > > copy maddr and port value from RECORD-ROUTE to ROUTE. > > If all parameters was copied instead it would be possible > > for a server to add anything it likes in RECORD-ROUTE > > and get it back again. I beleave this kind of solution > > have been discussed for states ? > > > > /Bertil > > > > Bertil Engelholm wrote: > > > > > > Hi again, > > > > > > I'm sorry to bring this up again but I just can't get things > > > to work in the correct way. I have read through the old threads > > > regarding this matter and still don't understand how it is > > > suppose to work. > > > > > > It's this example again : > > > > > > --------- -------- -------- > > > | a@c1 | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> | | > > > --------- (contact a@c1) | | | | > > > | p1 | | p2 | > > > --------- | | | | > > > | b@c2 | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- | | > > > --------- -------- -------- > > > > > > If P1 is stateful it might allocate one "call" state machine for > > > each path the "call" takes in P1 (s1 and s2 in the picture). > > > These two state machines are identified by the REQUEST-URI > > > that came in the two INVITEs since that's the only thing that > > > differs the two from each other. (topmost VIA also differs, > > > more about that later) > > > > > > P1 will now include the REQUEST-URI in the branch value it > > > generates so that the responses can be directed to the right > > > state machine when they arrive. And when the ACK is sent the > > > original REQUEST-URI from ROUTE is used. So no problems here. > > > > > > The problem I have is when b@C2 sends a new request (eg. BYE). > > > According to the specification b should/must/may (or whatever) > > > overwrite the REQUEST-URI in the ROUTE headers using the > > > REQUEST-URI from CONTACT or FROM. > > > > > > So how should P1 now be able to differ the two (BYE) requests > > > from each other ? The Original REQUEST-URI was the only thing > > > that P1 had to identify the two state machines. > > > > > > When reading the old threads regarding this matter I saw > > > something about using topmost VIA in some way, but how ? > > > > > > By using the topmost VIA you can see that they are two different > > > requests but how do you identify which state machine should receive > > > the first request. (Someone might argue that it doesn't > > matter but if > > > P1 controls a firewall it DO matter. Maybe not for BYE but for a > > > RE-INVITE it matters). > > > > > > -- > > > Bertil Engelholm > > > AXE Research and Development voice : +46 8 727 3499 > > > SIP Security Fax : +46 8 647 8276 > > > S-126 25 Stockholm Sweden E-mail: > > > Bertil.Engelholm@uab.ericsson.se > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Bertil Engelholm > > AXE Research and Development voice : +46 8 727 3499 > > SIP Security Fax : +46 8 647 8276 > > S-126 25 Stockholm Sweden E-mail: > > Bertil.Engelholm@uab.ericsson.se > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Bertil Engelholm AXE Research and Development voice : +46 8 727 3499 SIP Security Fax : +46 8 647 8276 S-126 25 Stockholm Sweden E-mail: Bertil.Engelholm@uab.ericsson.se _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 09:22:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04759 for ; Mon, 6 Nov 2000 09:22:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F8E644338; Mon, 6 Nov 2000 08:22:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rautu.eng.telia.fi (ts003d08.tam-fl.concentric.net [206.173.66.116]) by lists.bell-labs.com (Postfix) with ESMTP id 17BD244337 for ; Sun, 5 Nov 2000 17:55:12 -0500 (EST) Received: (from jh@localhost) by rautu.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id WAA00404; Sun, 5 Nov 2000 22:50:47 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14853.51239.142296.373172@rautu.eng.telia.fi> To: Jonathan Rosenberg Cc: "'Christer Holmberg'" , sip@lists.bell-labs.com, Igor Slepchin , sean.olson@ericsson.com Subject: RE: [SIP] Redirect server returning new From header In-Reply-To: References: 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: Sun, 5 Nov 2000 22:50:47 +0200 (EET) Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > As Henning pointed out previously, allowing a UAC to insert a telephone > number into a request, which is then passed to the PSTN (via a gateway) as > the originating number, is a recipe for a security disaster. Nothing stops > me from inserting fake telephone numbers, and calling people pretending to > be someone else. You can expect a call from the FCC about that one. why is that? the proxy receives the invite message and authenticates it. then it checks from the user database if the telephone number in the from field is among those that has been allocated to the user. if so, it accepts the call and passes it to the uas at the pstn gw. if not, it rejects the invite. the uas only talks to the proxy and thus knows that it can use the number in the from field as calling party number. > So, in fact, this proposed used of the Also-From header is, in practice, > unusable without a massive security/PKI infrastructure which really doesn't > exist (you would need someone to certify that joe@foo.com owns the number > 555-1212. I don't even know who would be able to adequately certify this, > and I suspect no CA in their right mind would ever put this in a > certificate). if the user is my pstn customer, i have a record of the numbers that have been allocated to it. > > Perhaps I sound harsh, but I am trying really hard to push back on everyones > "lets add X to SIP" request. SIP is already an RFC, folks. We are obliged to > carefully scrutinize everything that gets added, and only put things in when > they are truly needed, broadly useful, and backwards compatible. This > Also-From thing has only one proposed application, which is interoperation > with the PSTN, and in this application is frought with serious security > issues. i too think that it is very bad idea to keep on adding new headers to sip requests. in some cases though, it would be nice if the proxy would be allowed to rewrite the from address. -- juha _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 09: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 JAA05730 for ; Mon, 6 Nov 2000 09:25:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B477D4433F; Mon, 6 Nov 2000 08:25:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 2679344337 for ; Mon, 6 Nov 2000 08:24:54 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id IAA06812; Mon, 6 Nov 2000 08:24:47 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id IAA22480; Mon, 6 Nov 2000 08:24:47 -0600 (CST) Received: from ericsson.com (kipe51.eraj.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA05791; Mon, 6 Nov 2000 08:24:45 -0600 (CST) Message-ID: <3A06BF29.ED8A62BB@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: Re: [SIP] Identification 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 06 Nov 2000 15:24:41 +0100 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > So, perhaps we should consider defining address and port record-route > parameters. These would only be set when the request URI contained a non-SIP > URL. Proxies would use these parameters if present for routing instead of > the maddr and port in the URL. > > COmments? (I'm sure there are). > -Jonathan R. I like this approach except I would take it a step further and do this for all URLs including SIP URLs. This allows maddr to go back to its original intention for SIP URLs. Plus I hate special cases; this seems (nominally) easier to implement. /sean -- Sean Olson Ericsson 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 Nov 6 09:32: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 JAA08197 for ; Mon, 6 Nov 2000 09:32:28 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B84544346; Mon, 6 Nov 2000 08:26:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id C666A44337 for ; Mon, 6 Nov 2000 08:25:47 -0500 (EST) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eA6EPft22450; Mon, 6 Nov 2000 15:25:41 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id eA6EPen18597; Mon, 6 Nov 2000 15:25:41 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id PAA15374; Mon, 6 Nov 2000 15:25:39 +0100 (MET) Message-ID: <3A06BF63.9C510F3@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Cc: Neil Deason , Jonathan Rosenberg Subject: Re: [SIP] Identification problem References: <8u6b23$8ad$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 06 Nov 2000 15:25:39 +0100 Content-Transfer-Encoding: 7bit Neil Deason wrote: > > Jonathan Rosenberg wrote: > > [snip] > > > > Now, to make things more complex, we have a slight problem that > > record-routing has troubles when the request URI in the incoming request is > > not a SIP URL. Thats because, as you may recall, the RR process in a proxy > > is to COPY the request URI into the RR, and then modify the maddr and port. > > Now, maddr and port are SIP URL parameters. There are no such things for the > > tel URL, for example. Thus, record routing a request with a tel URL is a bit > > problematic. You basically need to convert it to a SIP URL first, or do > > something else. Converting everything to SIP URLs may not always be possible > > down the road. One can make the argument, and I would agree with it, that > > the IP address and port of the proxy are not URI parameters, but > > record-route header parameters. We did the hack of putting them in the URI > > maddr and port since this is backwards compatible. > > > > So, perhaps we should consider defining address and port record-route > > parameters. These would only be set when the request URI contained a non-SIP > > URL. Proxies would use these parameters if present for routing instead of > > the maddr and port in the URL. > > There is a potential problem here and this looks like a > reasonable solution. Pitty we can't extend it to all URLs. This is close to a solution I would like to have. I would like to always have RR-parameters instead of URI-parameters. The UA MUST always copy the complete RR-header(s) (including RR-parameters) into ROUTE. The UAS then take the contact/from URI and copy it into ROUTE-URI. The only problem is to get the RR-parameters back to the server that created them. Either the servers have to copy the complete ROUTE header up as request-URI (including the original RR-parameters) or the ROUTE behaviour is changed so it behaves as VIA ie. a server removes it's "own" ROUTE header instead of removing the next servers ROUTE header. In this way you can add any parameters you like in the RECORD-ROUTE and then get it back in ROUTE. This is maybe to ask for too much but I beleave such a solution would open up many new possibilities i.e. state transfer, call state identification etc. /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 Nov 6 09:56: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 JAA15489 for ; Mon, 6 Nov 2000 09:56:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CF16E44338; Mon, 6 Nov 2000 08:56:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A4F6344337 for ; Mon, 6 Nov 2000 08:55:08 -0500 (EST) Received: from CINQUECENTO ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id JAA02952; Mon, 6 Nov 2000 09:56:59 -0500 (EST) From: "Robert Sparks" To: Cc: Subject: RE: referred-by syntax (was RE: [SIP] (no subject)) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <6525698A.004342C2.00@sampark.hss.hns.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 6 Nov 2000 08:53:20 -0600 Content-Transfer-Encoding: 7bit It's going to be a few more days before I can get the next revision of the REFER draft out. Until then, here's what list discussion has guided the Referred-By syntax into. The motivations for change were 1) Allow URLs containing semicolons to be parsed correctly. This introduced changing the referrer-url from SIPURL to name-addr | addr-spec. Allowing the referrenced URL to be separated is a little more difficult since it is not necessarily a SIP URL. This syntax attempts to resolve the problem by wrapping the URL with <> and requiring any <>s appearing in the URL to be escaped. 2) Allow the parameters to be completely unordered. This requires more text to augment the ABNF. ------------------- Referred-By = ("Referred-By" | "b") ":" referrer-url *( ";" referenced-url | ";" ref-signature ) referrer-url = ( name-addr | addr-spec ) referenced-url = "ref" "=" "<" URL ">" ref-signature = signature-scheme *( ";" sig-scheme-params ) signature-scheme = "scheme" "=" token sig-scheme-parms = token "=" ( token | quoted-string ) A Referred-By header MUST contain exactly one referenced-url. A Referred-By header MUST contain either zero or one ref-signature. Any occurences of "<" or ">" within the URL value in referenced-url must be escaped. ------------ 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 Nov 6 10:16: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 KAA21756 for ; Mon, 6 Nov 2000 10:16:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 552E744338; Mon, 6 Nov 2000 09:16:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by lists.bell-labs.com (Postfix) with ESMTP id 0633C44337 for ; Mon, 6 Nov 2000 09:15:34 -0500 (EST) Received: from oleane (dyn-1-1-152.Vin.dialup.oleane.fr [195.25.4.152]) by smtp2.cluster.oleane.net with SMTP id QAA34694 for ; Mon, 6 Nov 2000 16:15:27 +0100 (CET) Message-ID: <00f101c04804$d00a9f40$8001a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01C0480D.317379C0" 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] IP.Net Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 6 Nov 2000 16:18:26 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C0480D.317379C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IP.Net=20 The IP private networks 2001 Event: VPNs, security, VoIP, broadband access, SLAs. A call for proposals is online at: http://www.upperside.fr/baipnet.htm ------=_NextPart_000_00EE_01C0480D.317379C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IP.Net =
The IP private networks 2001 Event:
VPNs, security, VoIP, broadband = access,=20 SLAs.
A call for proposals is online = at:
http://www.upperside.fr/baip= net.htm
------=_NextPart_000_00EE_01C0480D.317379C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 10:55: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 KAA02452 for ; Mon, 6 Nov 2000 10:55:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A1E744338; Mon, 6 Nov 2000 09:55:07 -0500 (EST) 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 017C144337 for ; Mon, 6 Nov 2000 09:54:07 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon Nov 6 10:52:33 EST 2000 Received: by lists.bell-labs.com (Postfix) id 15EB244380; Mon, 6 Nov 2000 10:39:24 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 9BCE24437D for ; Mon, 6 Nov 2000 10:39:23 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4Y6PPGB0>; Mon, 6 Nov 2000 15:39:23 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00BD014@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'james jack'" , "SIP@lists.bell-labs.com" , "'Jonathan Rosenberg'" Subject: RE: [SIP] discussion MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 6 Nov 2000 15:39:17 -0000 Some minor tweaks to the original proposal, with the aim of aligning all the text into a common format, and ensuring that we have a clearly specified set of sender and receiver requirements, and not with any aim of technically changing it.. > The header fields required, optional, and not applicable for each method > are listed in Table 4 and Table 5. The table uses "o" to indicate > optional, "m" mandatory and "-" for not applicable. > "Optional" means that a UAC \MAY include the header in a request, and a UAS \MAY ignore the header if present in the request. Similarly, an optional response header implies that a UAS \MAY place the header in a response, and the UAC \MAY ignore the header if present in a response it receives. "Mandatory" means the UAC \MUST include the header in a request, and a UAS \MUST understand the header if present in a request it receives. Similarly, a mandatory response header implies that a UAS \MUST place the header in a response, and the UAC \MUST understand the header if present in a response it receives. > "Not applicable" means the UAC \SHOULDNOT include the header in a request, > and a UAS \SHOULD ignore the header if present in a request it receives. > Similarly, a not applicable response header implies that a UAS \SHOULDNOT > place the header in a response, and the UAC \SHOULD ignore the header if > present in a response it receives. > > "m*" means the UAC \SHOULD include the header in a request, and a UAS > \MUST process requests without that header field. Similarly, a mandatory > response header implies that a UAS \SHOULD place the header in a response, > and the UAC \MUST process responses without that header field. > Editorial note: Not sure about the phrasing of the receiver requirement in the above paragraph, but there is definitely a receiver requirement needed. > A "*" indicates that the header fields are needed only if message body is > not > empty. See sections 6.18, 6.19 and 8 for details. > Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > Sent: 31 October 2000 16:58 > To: 'james jack'; SIP@lists.bell-labs.com > Subject: RE: [SIP] discussion > > These are ignored. Thats what optional means, although this probably needs > to be clarified. The text in Section 6 currently reads: > > The header fields required, optional and not applicable for each method > are > listed in Table 4 and Table 5. > The table uses "o" to indicate optional, "m" mandatory and "-" for not > applicable. "m*" indicates a header > that SHOULD be sent, but servers need to be prepared to receive requests > without that header field. A "*" > indicates that the header fields are needed only if message body is not > empty. See sections 6.18, 6.19 and 8 > for details. > > > I would suggest: > > The header fields required, optional, and not applicable for each method > are > listed in Table 4 and Table 5. The table uses "o" to indicate optional, > "m" > mandatory and "-" for not applicable. Optional means that a UAC \MAY > include > the header in a request, and a UAS \MAY ignore the header if present in > the > request. Similarly, an optional response header implies that a UAS \MAY > place the header in a response, and the UAC \MAY ignore the header if > present in a response it receives. A mandatory request header means the > header \MUST be present in a request, and \MUST be understood by the UAS > receiving the request. A mandatory response header means the header \MUST > be > present in the response, and the header \MUST be understood by the UAS > processing the response. "Not applicable" for request headers means the > header \SHOULDNOT be present in a request. If one is placed in a request, > it > \SHOULD be ignored by the UAS receiving the request. Similarly, a header > "not applicable" for a response means the UAS \SHOULDNOT place the header > in > the response, and the UAC \SHOULD ignore the header in the response. "m*" > indicates a header > that SHOULD be sent, but servers need to be prepared to receive requests > without that header field. A "*" > indicates that the header fields are needed only if message body is not > empty. See sections 6.18, 6.19 and 8 > for details. > > > > Sound OK? > > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: james jack [mailto:sipjames@yahoo.com] > > Sent: Tuesday, October 31, 2000 7:02 AM > > To: SIP@lists.bell-labs.com > > Subject: [SIP] discussion > > > > > > Dear All: > > I have one question to ask, If an request > > contains > > One header that is not applicable according to > > RFC2543bis > > 02, for example, in REGISTER request, there appear > > Alert-info, Priority, > > how to cope with this request, 400 response code or > > discard this header > > and continue to process? > > Could anyone give me some advice or suggestion > > for processing such stuation? > > Best regards! > > Yours:james > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Messenger - Talk while you surf! It's FREE. > > http://im.yahoo.com/ > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 11:45:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16589 for ; Mon, 6 Nov 2000 11:45:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9396D44339; Mon, 6 Nov 2000 10:45:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 4A02A44337 for ; Mon, 6 Nov 2000 10:44:55 -0500 (EST) 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 LAA12491; Mon, 6 Nov 2000 11:44:48 -0500 (EST) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id LAA26562; Mon, 6 Nov 2000 11:44:48 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14854.57343.938642.745445@conrail.cs.columbia.edu> To: Tajindrapal Singh Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Help with installation of sipd In-Reply-To: <200011032322.SAA03901@arctic.cse.msu.edu> References: <200011032322.SAA03901@arctic.cse.msu.edu> 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: Mon, 6 Nov 2000 11:44:47 -0500 (EST) Content-Transfer-Encoding: 7bit On Friday, November 3 2000, "Tajindrapal Singh" wrote to "sip@lists.bell-labs.com" saying: > Hi, > We are trying to install sipd (columbia release) on a linux box. But, before compiling sipd server, do we need to install the LDAP (Umich distribution)? If so then I guess we need root access for installation of LDAP?? No -- all you need is write access to a directory where you can install ldap binaries. > In the README.build of sipd there is an example for configuring as follows: > > ./configure --with-db=/proj/irt-gc4/cinema/sun5 \ > --with-ldap=/proj/irt-gc4/cinema/sun5 > > Now, we are not sure as to what should be in the sun5 directory? Should there be the sources for LDAP and berkely db? OR Is it the executables that needs to be present in this Any? That should be the root of the installation directory for ldap and Berkeley DB. I.e., on our platform, the directory /proj/irt-gc4/cinema/sun5/lib contains libdb.a, liblber.a, and libldap.a, and /proj/irt-gc4/cinema/sun5/include contains db.h, lber.h, and ldap.h (and other support files). -- 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 Mon Nov 6 11:58:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21341 for ; Mon, 6 Nov 2000 11:58:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06E654433D; Mon, 6 Nov 2000 10:58:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2372444337; Mon, 6 Nov 2000 10:57:07 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA13229; Mon, 6 Nov 2000 11:56:59 -0500 (EST) Message-ID: <3A06E2DC.E2EBE99D@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com, IPTEL@lists.bell-labs.com, tccc@ieee.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] CFP: 2nd IP Telephony Workshop - Deadline 11/27/00 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 06 Nov 2000 11:57:00 -0500 Content-Transfer-Encoding: 7bit Call for Papers 2nd IP Telephony Workshop April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ---------- Internet telephony is rapidly evolving from research to design and deployment. The objectives of the IP Telephony Workshop are to bring together researchers, developers, vendors and service providers active in this area and stimulate discussion on innovation, research, implementation, deployment experiences and future directions. Scope & Topics -------------- Original technical articles related to IP telephony are solicited. Only papers with significant technical content, not "white papers" or tutorials, will be considered for publication: - Research papers (unique ideas, novel algorithms, architectures, measurements, theoretical and/or analytical contributions) - Surveys, state-of-the-art studies, technology comparisons - Implementation and deployment reports - Standardization reports Particular areas of interest include, but are not limited to, the following: - Integration with Internet services (e.g., web, instant messaging, games) - Added-value services (e.g., call centers, conferencing) - Mobility and 3rd generation wireless - Authentication, authorization, accounting, charging, settlement - QoS support - Security (e.g., privacy, authentication, certification authorities, firewall traversal) - Call signaling & processing - Feature creation - Supporting services (e.g., call routing, lookup services) - Audio & video encoding and transmission - Management and provisioning - Interworking with the PSTN - Design and deployment considerations (e.g., performance, scalability, reliability) Important Dates --------------- Full paper due November 27th, 2000 Notification of acceptance January 12th, 2001 Final version due January 31st, 2001 Program published and February 5th, 2001 registration opens Workshop April 2nd-3rd, 2001 Submission Instructions ----------------------- Authors are invited to submit full papers written in English before November 27th, 2000. The submissions will be reviewed, and accepted papers will be included in the program. Notifications of acceptance will be sent out on January 12th, 2000. Deadline for submission of camera-ready copies is January 31st, 2001. Authors of accepted papers will need to sign a Copyright Transfer Form and submit a Netbib entry. Papers must be submitted electronically using the Web site at http://www.cs.columbia.edu/iptel Submissions must be in PDF or Postscript; any other documents cannot be accepted. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. Papers must be formatted according to the IEEE Transactions format except for the font size, which MUST be 11pt. Templates are available at the Web site http://www.fokus.gmd.de/events/iptel2001/cfp/ Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, papers with more than 11 pages cannot be reviewed. Submissions must include: title, authors, affiliation, abstract, list of keywords, and contact information. One of the authors of each accepted paper must present the paper at iptel'2001. Contact Address --------------- Please, send all your inquiries regarding iptel2001 to iptel2001@egroups.com. -- 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 Nov 6 12:57:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11365 for ; Mon, 6 Nov 2000 12:57:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E658F4433A; Mon, 6 Nov 2000 11:57:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id B282044337 for ; Mon, 6 Nov 2000 11:56:11 -0500 (EST) Received: from blanc.cisco.com (blanc.cisco.com [161.44.3.203]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA18586 for ; Mon, 6 Nov 2000 09:56:08 -0800 (PST) From: David Daiker To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] 200 OK Contact, firewalls, record-route Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 6 Nov 2000 12:55:36 -0500 (EST) I have a couple of questions regarding the interaction of the contact header in the 200 OK, firewalls, and record-route The spec says that a UA behind a firewall, provides the ip of the firewall as its contact address, and if record-route headers exist, this address is appended (by the UAC) to the route for subsequent requests. My question is this - what if the firewall proxy, due to some independent feature logic, already added a record-route of itself to the request ? Should the UAC that builds the route, verify that the route is not already present before appending the contact address ? Along those same lines, what should a proxy do that sees itself as the next route ? The spec says it should forward it unless that will cause a loop. So, should it return a loop detected error ?, pop that route, and forward it to the next route ?, or route based upon the URI ? thanks, david _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 14:08: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 OAA27533 for ; Mon, 6 Nov 2000 14:08:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A08744338; Mon, 6 Nov 2000 13:08:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 3144144337 for ; Mon, 6 Nov 2000 13:07:12 -0500 (EST) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G3M9Z700.LLZ for ; Mon, 6 Nov 2000 10:57:07 -0800 Message-ID: <3A070151.8C559E3C@vovida.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: [SIP] putting media on hold References: <3A034C87.EA59D978@vovida.com> Content-Type: multipart/alternative; boundary="------------C7AE93654F0CB74A72659D57" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 06 Nov 2000 11:06:57 -0800 --------------C7AE93654F0CB74A72659D57 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, according to section B. 6 in a new draft it is possible to put the other party "on hold", that is to ask it temporarily stop sending media, by sending re-INVITE with the destina- tion addresses (c= lines) set to 0. What should we expect in 200 OK ? Should it be (upon acception of re-INVITE) the regular SDP with valid ports and destination addresses, since it stops sending, but still continue receiving ? Thanx. -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.com --------------C7AE93654F0CB74A72659D57 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,
    according to section B. 6 in a new draft it is possible to put the other party "on hold",
that is to ask it temporarily stop sending media, by sending re-INVITE with the destina-
tion addresses (c= lines) set to 0.
What should we expect in 200 OK ? Should it be (upon acception of re-INVITE) the
regular SDP with valid ports and destination addresses, since it stops sending, but
still continue receiving ?

Thanx.
  

-- 
Vladislav Zubarev        mailto:vladis@vovida.com
Software Engineer   
Vovida Networks, Inc.    http://www.vovida.com
  --------------C7AE93654F0CB74A72659D57-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 14:14: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 OAA28812 for ; Mon, 6 Nov 2000 14:14:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 786FC44338; Mon, 6 Nov 2000 13:14:06 -0500 (EST) 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 2016A44337 for ; Mon, 6 Nov 2000 13:13:18 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15211 for ; Mon, 6 Nov 2000 14:13:10 -0500 (EST) 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 OAA02092 for ; Mon, 6 Nov 2000 14:13:11 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 14:12:29 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E9C6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" 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] Appeal for Torture Test Code Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 6 Nov 2000 14:13:07 -0500 As we approach the next SIP Bake-off, we are trying to improve the body of tests called "Torture Tests". These are SIP message sequences that various parsers have had trouble with in the past. New implementations typically use these tests as the first level of interoperability testing. We would like to have message sequences that you think are legal, but you have seen a parser have trouble for one reason or another. It doesn't really matter what the message does, just that it be something a good implementation should be able to cope with. We are not really looking for you to get downright devious about it, but we would like all implementations to not choke on legal messages. If you have some, please email them to: Neil Deason [ndeason@ubiquity.net] who has volunteer to collate them. Thanks Brian _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 14:50:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07110 for ; Mon, 6 Nov 2000 14:50:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 36B1D44346; Mon, 6 Nov 2000 13:50:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id CE32644349 for ; Mon, 6 Nov 2000 13:49:46 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA24104 for ; Mon, 6 Nov 2000 12:49:40 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA15866 for ; Mon, 6 Nov 2000 12:49:39 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 6 Nov 2000 13:48:15 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED85F0@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Subject: [SIP] SIP negotiation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 3 Nov 2000 13:25:07 -0600 Sorry for the basic question.. but: How can two SIP end points negotiate QoS, Bandwidth, vocoders ? I mean how it is done as part of the call setup? how it may be done during the call? What headers are used for that (SIP headers?, SDP headers?) Thanks Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 17:22:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23356 for ; Mon, 6 Nov 2000 17:22:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 55D8444349; Mon, 6 Nov 2000 16:22:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver2.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id 40BBF44337 for ; Mon, 6 Nov 2000 16:21:08 -0500 (EST) Received: from 172.16.128.16 by mailserver2.sylantro.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Mon, 06 Nov 00 14:18:18 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver2.sylantro.com with Internet Mail Service ( 5.5.2650.21) id ; Mon, 6 Nov 2000 14:18:18 -0800 Message-ID: From: "Sunil Veluvali" To: "'Sunitha Kumar'" , "Mark Wisdom" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Digest Authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 1619F1A029034-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, 6 Nov 2000 14:18:14 -0800 Content-Transfer-Encoding: 7bit With respect to MD5 authentication, is the following the correct way to compute the response tag of the authentication header for a 401 Unauthorized? I am assuming cnonce, noncecount and qop are not specified. 1. get the method name from CSeq of the response 2. get nonce, realm from the WWW-Authenticate header 3. Query uid and password from user 4. Following RFC 2617, setup the following: nonce = WWW-Authenticate::nonce cnonce = "" user = query_user_for_uid() realm = WWW-Authenticate::realm password = query_user_for_password() algorithm = "MD5" noncecount = "" method = CSeq::method qop = "" uri = registrar 5. Calculate DigestCalcHA1(algorithm, user, realm, password, nonce,cnonce); 6. Calculate DigestCalcResponse(HA1, nonce,noncecount, cnonce, qop, method, uri, HA2, response); thanks, Sunil Veluvali Sylantro Systems -----Original Message----- From: Sunitha Kumar [mailto:skumar@vovida.com] Sent: Friday, October 20, 2000 10:54 AM To: Mark Wisdom Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Digest Authentication Mark: With respect to your question about mutual authentication, maybe PGP could be considered as the way to go. Using PGP, the server can authenticate the client, and the client could verify that this is the server. Using Digest for mutual authentication may require 2 independent msgs to go from the server to client and client to server, each sending each other their generated nonces, and the other forming the digest with that nonce. Just my 2c. sunitha Mark Wisdom wrote: I need some clarification on, and help with, digest authentication. rfc2617, section 3.2.1 states: > A nonce might, for example, be constructed as the base 64 > encoding of > > time-stamp H(time-stamp ":" ETag ":" private-key) Then in section 4.5 it states: > The server created "nonce" value is implementation dependent, > but if it contains a digest of the client IP, a time-stamp, > the resource ETag, and a private server key (as recommended > above) then a replay attack is not simple. rfc2543bis-02, section 14.3 states: > 4. The example procedure for choosing a nonce based on Etag > does not work for SIP. It would be nice if rfc2543 provided an alternate example for creating a nonce. Can this be added to the rfc2543? Does anyone have any guidelines on creating a nonce for use with digest authentication? rfc2543bis-02, section 14.3 also states: > 5. The Authentication-Info and Proxy-Authentication-Info > fields are not used in SIP. If I understand correctly, not allowing the Authentication-Info header eliminates support for mutual authenication (i.e. allowing the server to also authenticate itself to the client by proving to the client that it knows the client's secret). Does SIP allow for mutual authentication when using digest authentication? If not, can we modify rfc2543 so that mutual authentication is possible? Thanks, Mark Wisdom _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip -- Sunitha Kumar http://www.vovida.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 19:36:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13820 for ; Mon, 6 Nov 2000 19:36:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 371054433A; Mon, 6 Nov 2000 18:36:06 -0500 (EST) 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 6CAC644337 for ; Mon, 6 Nov 2000 18:35:33 -0500 (EST) Received: from tate ([64.241.199.100]) by broadsoft.com (8.8.8) id TAA37391; Mon, 6 Nov 2000 19:35:26 -0500 (EST) Message-ID: <03d001c04852$dbcdce30$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Vladislav Zubarev" , References: <3A034C87.EA59D978@vovida.com> <3A070151.8C559E3C@vovida.com> Subject: Re: [SIP] putting media on hold MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 6 Nov 2000 19:37:07 -0500 Content-Transfer-Encoding: 7bit If the held party wishes to still listen for something, it can send the same SDP as it previously sent. If the held party wishes the holder to quit streaming, it can increment the SDP and set the "c=" to 0.0.0.0 . ----- Original Message ----- From: Vladislav Zubarev To: sip@lists.bell-labs.com Sent: Monday, November 06, 2000 2:06 PM Subject: [SIP] putting media on hold Hello, according to section B. 6 in a new draft it is possible to put the other party "on hold", that is to ask it temporarily stop sending media, by sending re-INVITE with the destina- tion addresses (c= lines) set to 0. What should we expect in 200 OK ? Should it be (upon acception of re-INVITE) the regular SDP with valid ports and destination addresses, since it stops sending, but still continue receiving ? Thanx. -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.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 Nov 6 20:21: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 UAA28074 for ; Mon, 6 Nov 2000 20:21:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E3AF4433A; Mon, 6 Nov 2000 19:21:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 674E744337 for ; Mon, 6 Nov 2000 19:20:58 -0500 (EST) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G3MRAC00.2OA; Mon, 6 Nov 2000 17:11:00 -0800 Message-ID: <3A0758F3.4BC2A2A2@vovida.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Deleting media streams References: Content-Type: multipart/alternative; boundary="------------F84E925628458CD80C9840BE" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 06 Nov 2000 17:20:51 -0800 --------------F84E925628458CD80C9840BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What if the other party wishes still to receive media stream, is there any way we can get one-way stream, I mean the situation when one sends re-INVITE with RTP port set to 0 for some particular m= line, however another party replies with SDP with valid ports ? Do we get one-way stream in this case ? Thanx. Jonathan Rosenberg wrote: > > -----Original Message----- > From: Vladislav Zubarev [mailto:vladis@vovida.com] > Sent: Tuesday, October 31, 2000 3:48 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Deleting media streams > > >Hello, > > I have a question about deleting media stream procedure, described in a > new SIP draft > >(section B. 5). > > > >Let's say we opened two media streams, so now we send re-INVITE with SDP, > where one of the > >"m=" > > > >lines contains RTP port set to 0 - we would like to delete this particular > media stream. > > > >My question is what should we expect in 200 OK's SDP: should it contain the > same "m=" line > >with > > > >RTP port set to 0 or this "m=" line should be missing at all ? > > Same m line with port 0. > > There must always be the same number of m lines in the request as in the > response. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.com --------------F84E925628458CD80C9840BE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit What if the other party wishes still to receive media stream, is there any way we can get
one-way stream, I mean the situation when one sends re-INVITE with RTP port set to 0
for some particular m= line, however another party replies with SDP with valid ports ?
Do we get one-way stream in this case ?
Thanx.

Jonathan Rosenberg wrote:

 
-----Original Message-----
From: Vladislav Zubarev [mailto:vladis@vovida.com]
Sent: Tuesday, October 31, 2000 3:48 PM
To: sip@lists.bell-labs.com
Subject: [SIP] Deleting media streams

>Hello,
>    I have a question about deleting media stream procedure, described in a
new SIP draft
>(section B. 5).
>
>Let's say we opened two media streams, so now we send re-INVITE with SDP,
where one of the
>"m="
>
>lines contains RTP port set to 0 - we would like to delete this particular
media stream.
>
>My question is what should we expect in 200 OK's SDP: should it contain the
same "m=" line
>with
>
>RTP port set to 0 or this "m=" line should be missing at all ?

Same m line with port 0.

There must always be the same number of m lines in the request as in the
response.

-Jonathan R.

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

-- 
Vladislav Zubarev        mailto:vladis@vovida.com
Software Engineer   
Vovida Networks, Inc.    http://www.vovida.com
  --------------F84E925628458CD80C9840BE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 6 22:53:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25956 for ; Mon, 6 Nov 2000 22:53:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AD474433D; Mon, 6 Nov 2000 21:53:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 9FAFD44337 for ; Mon, 6 Nov 2000 21:52:12 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 19:52:44 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" 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] OPTIONS and out-of-band Route. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 6 Nov 2000 19:52:43 -0800 There's seems to be a lot of discussion lately about out-of band Route in INVITE. Here's a another reason for correct processing of "out-of-band" Route headers ("out-of-band" with respect to an INVITE initiated call-leg): When a UAC makes a OPTIONS request before performing a full INVITE, the UAS may include a Contact in the 200 OK which be used as the direct destination to send the initial INVITE. If a proxy needs to be on the path of the initial INVITE (eg proxy is acting as ALG) then the call will fail if the proxy and UAC doesn't take some additional action. DOn't we need to add something such as the following to the spec? 1)A proxy SHOULD insert a Record-Route entry for itself on all OPTION's requests, if it would have inserted itself on a corresponding INVITE. 2) UAC SHOULD generate a Route header (from the Record-Route in the OPTIONS response) in the subsequent initial INVITE request if - a Contact header in the OPTIONS 200 OK request is present and used. - a Record-Route header is also present in the OPTIONS response. [Actually a proxy should only need to insert itself into the Record-Route header of the OPTIONS _response_ if the response contains a Contact (because the reverse route will never be needed to an OPTIONS request); however this just complicates behaviours and so I the above is a better recommendation for the spec.] Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 01:40: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 BAA28327 for ; Tue, 7 Nov 2000 01:40:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C380C4433D; Tue, 7 Nov 2000 00:40:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3E87444337 for ; Tue, 7 Nov 2000 00:39:28 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09984; Tue, 7 Nov 2000 01:41:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPRK>; Tue, 7 Nov 2000 01:37:58 -0500 Message-ID: From: Jonathan Rosenberg To: "'Vladislav Zubarev'" , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: RE: [SIP] Deleting media streams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 01:37:53 -0500 -----Original Message----- >From: Vladislav Zubarev [mailto:vladis@vovida.com] >Sent: Monday, November 06, 2000 8:21 PM >To: Jonathan Rosenberg; sip@lists.bell-labs.com >Subject: Re: [SIP] Deleting media streams > > >What if the other party wishes still to receive media stream, is there any way we can get >one-way stream, I mean the situation when one sends re-INVITE with RTP port set to 0 >for some particular m= line, however another party replies with SDP with valid ports ? >Do we get one-way stream in this case ? No. In the case of a stream deletion, the response should always have a port of zero as well. If a UA wants to change a stream to send only or recv-only, it can do that by changing the sdp attribute for directions. -Jonathan R. -----Original Message----- From: Vladislav Zubarev [mailto:vladis@vovida.com] Sent: Tuesday, October 31, 2000 3:48 PM To: sip@lists.bell-labs.com Subject: [SIP] Deleting media streams >Hello, > I have a question about deleting media stream procedure, described in a new SIP draft >(section B. 5). > >Let's say we opened two media streams, so now we send re-INVITE with SDP, where one of the >"m=" > >lines contains RTP port set to 0 - we would like to delete this particular media stream. > >My question is what should we expect in 200 OK's SDP: should it contain the same "m=" line >with > >RTP port set to 0 or this "m=" line should be missing at all ? Same m line with port 0. There must always be the same number of m lines in the request as in the response. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.com --- 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 Nov 7 01:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02666 for ; Tue, 7 Nov 2000 01:47:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 65E9944354; Tue, 7 Nov 2000 00:47:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2B54244337 for ; Tue, 7 Nov 2000 00:46:07 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09996; Tue, 7 Nov 2000 01:48:19 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPRN>; Tue, 7 Nov 2000 01:44:38 -0500 Message-ID: From: Jonathan Rosenberg To: "'David Daiker'" , sip@lists.bell-labs.com Subject: RE: [SIP] 200 OK Contact, firewalls, record-route MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 01:44:29 -0500 > -----Original Message----- > From: David Daiker [mailto:ddaiker@cisco.com] > Sent: Monday, November 06, 2000 12:56 PM > To: sip@lists.bell-labs.com > Subject: [SIP] 200 OK Contact, firewalls, record-route > > > > I have a couple of questions regarding the interaction of the > contact header in the 200 OK, firewalls, and record-route > > The spec says that a UA behind a firewall, provides the ip of the > firewall as its contact address, and if record-route headers exist, > this address is appended (by the UAC) to the route for subsequent > requests. Be careful here. This treatment of Contact headers has about 1/2 sentence mention in the spec. I guess it deserves more explanation. The contact header sets the address where subsequent requests go. Thats it. Now, a smart network can be set up whereby the UA inserts the address of the firewall, and the firewall knows that this is happening, so it doesn't record-route, and knows to translate this to something internal when requests arrive. In other words, this capability needs to be used in a coordinated fashion. The proxy must know that the UA is doing something funky here. In general usage, it should not make this assumption. -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 Nov 7 02:01: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 CAA11997 for ; Tue, 7 Nov 2000 02:01:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E124944358; Tue, 7 Nov 2000 01:01:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 89BBE44337 for ; Tue, 7 Nov 2000 01:00:25 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA10046; Tue, 7 Nov 2000 02:02:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPRV>; Tue, 7 Nov 2000 01:58:49 -0500 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , Jonathan Rosenberg Cc: "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: RE: [SIP] Identification problem MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 01:58:42 -0500 > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Monday, November 06, 2000 5:14 AM > To: Jonathan Rosenberg > Cc: 'Bertil Engelholm'; SIP@lists.bell-labs.com > Subject: Re: [SIP] Identification problem > > > Jonathan Rosenberg wrote: > > > > > Am I missing the problem? The other RR suggestions are > > > certainly interesting ;) > > > > The problem is that the unique via branch param allows you to > > *differentiate* between each request, but there is no easy > way to know that > > a request corresponds to a specific state machine. Thats > because (1) the > > proxy immediately before and/or after P1 may not actually > record-route, so > > the branch param in the original INVITE could be totally > different from the > > one in the re-INVITE or BYE, and (2) proxy P1 has no way to > know what the > > branch param for requests in the REVERSE direction will > look like after the > > original INVITE. > > I agree there is this issue but is it really a problem for > the spec? It depends. The problem here is that if the proxy has some state which is different for each iteration of the request through the proxy, is there a way to associate each request with the right piece of state? I think this is a reasonable thing to expect to be possible, so the protocol should have some way of supporting it. Another potential solution is to slightly change the way Route headers are constructed. Right now, the spec says: ---- 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. Since the URIs contained in the Record-Route header fields are not useful for the reverse request path, the UA fills all other components of the Route name-addr value with the name-addr value found in the Contact or the From header field. The latter is used only if there is no Contact header field. ---- as I pointed out, this causes everything from the Contact/From to be copied into Route, EXCEPT port and maddr. How about if we say that the Route contains the user:password@host portion of the Contact/From, and everything else is copied from the Record-Route? THis would include unknown URL parameters. The advantage here is that one could insert URL parameters into the record-route, and get them back in the request URI. Not the prettiest way to go. We could, as an alternative, simply mandate the State header in the bis draft, which would provide a cleaner solution. >> So, perhaps we should consider defining address and port record-route >> parameters. These would only be set when the request URI contained a non-SIP >> URL. Proxies would use these parameters if present for routing instead of >> the maddr and port in the URL. >> >> COmments? (I'm sure there are). >> -Jonathan R. > >I like this approach except I would take it a step further and >do this for all URLs including SIP URLs. This allows maddr to go >back to its original intention for SIP URLs. Plus I hate special >cases; this seems (nominally) easier to implement. Conceptually that is clearly the better way. However, there is a backwards compatibility problem. Older rfc2543 implementations will use the maddr to forward (if they are working correctly, that is), but not an address parameter of the Route header. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (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 Nov 7 02:10:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22020 for ; Tue, 7 Nov 2000 02:10:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37B6344352; Tue, 7 Nov 2000 01:10:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C70A544337 for ; Tue, 7 Nov 2000 01:09:32 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA10071; Tue, 7 Nov 2000 02:11:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPR6>; Tue, 7 Nov 2000 02:08:00 -0500 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , sip@lists.bell-labs.com Subject: RE: [SIP] OPTIONS and out-of-band Route. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 02:07:52 -0500 > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Monday, November 06, 2000 10:53 PM > To: sip@lists.bell-labs.com > Subject: [SIP] OPTIONS and out-of-band Route. > > > > There's seems to be a lot of discussion lately about out-of > band Route in > INVITE. Here's a another reason for correct processing of > "out-of-band" > Route headers ("out-of-band" with respect to an INVITE > initiated call-leg): > > When a UAC makes a OPTIONS request before performing a full > INVITE, the UAS > may include a Contact in the 200 OK which be used as the > direct destination > to send the initial INVITE. If a proxy needs to be on the path of the > initial INVITE (eg proxy is acting as ALG) then the call will > fail if the > proxy and UAC doesn't take some additional action. > > DOn't we need to add something such as the following to the spec? Well, this is a symptom of a more general problem, which is what is the meaning of Record-Routing in requests in general, beyond INVITE. I would propose the following: If a proxy inserts a record-route into a request, that means it wishes to receive all subsequent requests, in both directions, that contain the same value of the To, From, and Call-ID. I like this, since then it works for MESSAGE and SUBSCRIBE, which have similar requirements. Now, to handle your OPTIONS case: If a UAC initiates a call to a host as the result of an OPTIONS query, it SHOULD use the same Call-ID as was used in the OPTIONS query. Note that as a result of standard Record-Routing rules, this INVITE will contain any routing information learned from the OPTIONS response. This is now much more general purpose. -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 Nov 7 02:25:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29756 for ; Tue, 7 Nov 2000 02:25:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C98A04434B; Tue, 7 Nov 2000 01:25:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id ACE5E44337 for ; Tue, 7 Nov 2000 01:24:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA10100; Tue, 7 Nov 2000 02:26:20 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPSC>; Tue, 7 Nov 2000 02:22:39 -0500 Message-ID: From: Jonathan Rosenberg To: "'Keith Robinson'" , Jonathan Rosenberg Cc: "'Christer Holmberg'" , sip@lists.bell-labs.com, Igor Slepchin , sean.olson@ericsson.com Subject: RE: [SIP] Redirect server returning new From header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 02:22:35 -0500 > -----Original Message----- > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > Sent: Thursday, October 26, 2000 12:01 PM > To: Jonathan Rosenberg > Cc: 'Christer Holmberg'; sip@lists.bell-labs.com; Igor Slepchin; > sean.olson@ericsson.com > Subject: RE: [SIP] Redirect server returning new From header > > > > > With respect to the issue of delivering a calling line > identity from a SIP user > into the PSTN, consider the following. > > A SIP user wishes to be globally reachable; as this means he > has to be reachable > from a POTS subscriber in the PSTN who can only dial digits > it follows that the > SIP user must also be known by a dialled digit string. Therefore, the > association of the SIP users URL and the dialled digit string > to reach this URL > must be fixed so therefore verifiable; if this were not the > case then calls from > the PSTN into SIP networks could not happen. Well, such mappings (from a phone number to a SIP URL) are the subject of enum. Who owns such mappings, and how they are managed, is currently the subject of intense political and regulatory struggles. I'm hoping to stay away from such things. > > The UAC should not be allowed to supply the CLI; rather it > is supplied by the > network to which he is connected and it is the responsibility > of the network to > ensure that the person is who he says he is (verify FROM:) > and ensure that the > correct CLI is delivered. In this case, I would argue that what you want is to use the privacy spec: http://search.ietf.org/internet-drafts/draft-dcsgroup-sip-privacy-02.txt but always use a telephone number in there. All this network-level authentication of names is very much a PSTN thing. I suspect the Remote-Party-ID identification will be used most commonly in PSTN bypass or PSTN emulation, in which case you only ever want a PSTN number anyway. For IP to IP signaling, an end to end authentication mechanism is preferrable. The next best thing is to update the privacy spec to allow multiple addresses in there. This way, you don't touch the base spec, which is what I really, really want to avoid. Simon writes: > > So, in fact, this proposed used of the Also-From header is, > in practice, > > unusable without a massive security/PKI infrastructure > which really doesn't > > exist (you would need someone to certify that joe@foo.com > owns the number > > 555-1212. I don't even know who would be able to adequately > certify this, > > and I suspect no CA in their right mind would ever put this in a > > certificate). > > This security infrastructure already exists in the current > telephone network - > although it is implemented in hardware rather than software. > Phone companies have a > network of trust with each other, and exchange ISUP messages > with each other only > secure lines setup along these lines of trust. Where > signalling is exchanged with an > end user (Q.931) checks are made to ensure the user is > authorised to send the numbers > he sends. A similar trust network is required if we want to > have authenticated CLI in > SIP. Currently SIP-T does require exactly the same (physical > or secure VPN) trust > network as regular ISUP telephony. Indeed this is probably > one of the main > constraining factors that limits whom SIP-T is available to. Huh? SIP-T does not anywhere require the same trust network as regular ISUP telephony. Where in the drafts does it say that? Juha writes: > > As Henning pointed out previously, allowing a UAC to > insert a telephone > > number into a request, which is then passed to the PSTN > (via a gateway) as > > the originating number, is a recipe for a security > disaster. Nothing stops > > me from inserting fake telephone numbers, and calling > people pretending to > > be someone else. You can expect a call from the FCC about that one. > > why is that? the proxy receives the invite message and authenticates > it. then it checks from the user database if the telephone number in > the from field is among those that has been allocated to the user. if > so, it accepts the call and passes it to the uas at the pstn > gw. if not, > it rejects the invite. the uas only talks to the proxy and thus knows > that it can use the number in the from field as calling party number. If the calling UA is known only by this number, you are correct. The privacy specification addresses exactly this requirement. The problem is when I make a call from my yahoo SIP account (sip:jdrosen@yahoo.com), and the yahoo proxy needs to insert my phone number into the request. What I am saying is that since yahoo does not own or adminster the PSTN numbering space, it has no way to verifiably correlate my yahoo address with my phone number. The same problem exists in the reverse; my phone company has no easy way to reliably verify that a valid additional sip address for me is jdrosen@yahoo.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: (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 Nov 7 02:28:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01394 for ; Tue, 7 Nov 2000 02:28:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56F5344367; Tue, 7 Nov 2000 01:28:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 0DDBA44337 for ; Tue, 7 Nov 2000 01:27:37 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 23:28:09 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com Subject: RE: [SIP] OPTIONS and out-of-band Route. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 6 Nov 2000 23:28:08 -0800 > > If a proxy inserts a record-route into a request, that means > it wishes to > receive all subsequent requests, in both directions, that > contain the same > value of the To, From, and Call-ID. > > I like this, since then it works for MESSAGE and SUBSCRIBE, which have > similar requirements. Agreed. Much more general. > Now, to handle your OPTIONS case: > > If a UAC initiates a call to a host as the result of an > OPTIONS query, it > SHOULD use the same Call-ID as was used in the OPTIONS query. > Note that as a > result of standard Record-Routing rules, this INVITE will contain any > routing information learned from the OPTIONS response. > My only comment here is that Section 11 & 12 on the behavior of UAC's and proxies is written from the point of view that a Call State Machine is created by an "initial INVITE request". I believe it is this idea, that is, importing "out-of-band" Route information from _before_ the Initial INVITE Request, that is cause of the recent discussions/queries/confusion in this area. In other words, in my mind the existing Record-Route rules description doesn't quite stretch to unambiguously cover the pre-initial-invite behaviour. I think a small clarification would be helpful. Cheers, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 02:44: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 CAA09208 for ; Tue, 7 Nov 2000 02:44:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FE554436B; Tue, 7 Nov 2000 01:44:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E889044337 for ; Tue, 7 Nov 2000 01:43:49 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA10161; Tue, 7 Nov 2000 02:45:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPSR>; Tue, 7 Nov 2000 02:42:09 -0500 Message-ID: From: Jonathan Rosenberg To: "'Samorezov Vladimir'" , sip@lists.bell-labs.com Subject: RE: [SIP] failure of proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 7 Nov 2000 02:42:00 -0500 -----Original Message----- >From: Samorezov Vladimir [mailto:samorezov@rts.loniis.ru] >Sent: Saturday, November 04, 2000 4:42 AM >To: sip@lists.bell-labs.com >Subject: [SIP] failure of proxy > > >Hi, all! >Could you help me in my SIPs study? >If proxy forwards a SIP request, it add Via header with its address. This ensures responses >take the same path as the requests. OK! >If one proxy along the path is failure, what upstream proxy must do to route responses? > >Thank you! >Samorezov Vladimir. This question is well timed. I've been having lots of private discussions on just this subject, and I think we've got the solutions all worked out. There are two cases here. One is routing of responses, and the other of subsequent requests. Regarding responses. The specific case is when proxy P1 forwards a request to P2, and before the response comes, P1 fails. How does P2 forward the response? This is related to what gets inserted into the Via header, and its relation to the received param. Now, the current text states that if the senders address is wrong, the proxy inserts the received param. However, if the sent-by field in the Via contains a hostname that resolves to an SRV record with many IP addresses, what is the meaning of "wrong"? The question came up on a previous thread a long time ago, and the answer I gave was that you would insert the received param if the source IP address in the request didn't match any of the servers listed in DNS. I beleive now that this is not the right solution. Rather, if the Via header contains a sent-by value thats a domain name, the next hop should always insert a received param with the source IP address. Why is that? To deal with failures. P2 would sent the response to the address in the received param. If it fails, P2 can instead take the hostname in the sent-by field, and look that up in DNS to find an alternate server to forward the response to. THis way, we can route responses around failures, but under normal operation, ensure responses get routed back to the actual server which forwarded the request. The second case is routing of subsequent requests. Lets say we send an initial INVITE, and proxy P1 and P2 record-route. Now, midway through the call, the proxy P2 fails. The caller sends a BYE. This hits P1. It sees a Route header in the request (pointing to P2), pops it, and tries to send it there. As this contains an maddr for P2, the request fails. In this case, I would argue that P1 should then try the SRV procedure once more on the host portion of the request URI, using the next server in DNS. For things to work consistently, the SRV lookup process should be based on the pseudo-random number generator I suggested in a previous thread; thats the one based on a hash of the Call-ID, amongst other things. This gives us consistent operation for SRV records in general. Now, an interesting thing to note here. Lets say in this failure case, it was the called party that hung up. The proxy downstream from P2 (say, P3), pops its top Route, and tries to forward it to P2. But, that maddr (pointing to P2), generates an ICMP error. So, it looks up the host portion of the request URI in DNS and tries the SRV process from there. I will note that this will only succeed if, and only if, *THE REQUEST URI ALWAYS REFERS TO THE RESOUCE FOR WHOM THE REQUEST IS DESTINED*. Now, this relates to a previous thread. The issue there was how a UAS would construct the Route headers, and whether we should maintain this property that the R-URI always refers to the entity for whom the request is targeted. I originally felt this was critical, and was coming close to backing down. Now, it seems we have another case to back up my original claim that maintaining this property is important. I'll make sure verbiage gets added to the spec on these failure handling cases. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 02:48: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 CAA11094 for ; Tue, 7 Nov 2000 02:48:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8BA2844359; Tue, 7 Nov 2000 01:47:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 02CF344337 for ; Tue, 7 Nov 2000 01:46:42 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 23:47:15 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" Cc: sip@lists.bell-labs.com Subject: User Identity (was [SIP] Redirect server returning new From heade r) 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, 6 Nov 2000 23:47:14 -0800 > If the calling UA is known only by this number, you are > correct. The privacy > specification addresses exactly this requirement. The problem > is when I make > a call from my yahoo SIP account (sip:jdrosen@yahoo.com), and > the yahoo > proxy needs to insert my phone number into the request. What > I am saying is > that since yahoo does not own or adminster the PSTN numbering > space, it has > no way to verifiably correlate my yahoo address with my phone > number. The > same problem exists in the reverse; my phone company has no > easy way to > reliably verify that a valid additional sip address for me is > jdrosen@yahoo.com. Hi Jonathan, Just because the SIP From address is jdrosen@freeemail.com, why is it not possible for your phone company to identify you and hence determine the correct CLI for the Remote-Party-Id? [I am assuming there is no sharing of information between your email provider and your phone company ..... but who knows what goes on these days.] What about "digital me" (www.digitalme.com) or verisign-like identification certificates that allow multi-realm/universal identity authentication? What about when these things become more prevalent? I ahven't looked into exactly how these things work but should you be able to establish identity without a direct security relationship between SIP endpoints, right? Cheers, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 02:57: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 CAA14940 for ; Tue, 7 Nov 2000 02:57:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A74D444373; Tue, 7 Nov 2000 01:50:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2D4AD44337 for ; Tue, 7 Nov 2000 01:49:12 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA10194; Tue, 7 Nov 2000 02:51:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPSZ>; Tue, 7 Nov 2000 02:47:29 -0500 Message-ID: From: Jonathan Rosenberg To: "'David Shrader'" , Henning Schulzrinne Cc: SIP List Subject: RE: [SIP] rfc2543bis comment/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, 7 Nov 2000 02:47:26 -0500 I think this note is simply wrong. I don't even remember noticing it until you pointed it out. Its in both bis and rfc2543. It should be stricken. Henning - do you agree? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: David Shrader [mailto:dshrader@master-consultant.com] > Sent: Saturday, November 04, 2000 12:29 AM > To: Henning Schulzrinne > Cc: SIP List > Subject: [SIP] rfc2543bis comment/question > > > Table 5 contains a note 2 regarding the Via field. It states > that the UAS > removes first Via header field. This seems to be in direct > contradiction to > the purpose of the Via field. When that proxy receives the > response, if > there is no Via field in it, then 1) it can't know that it is > meant for it > and 2) it wouldn't be able to identify the branch without the branch > parameter. > > Am I missing something? What was meant by the note in Table 5? > > ---------------------------- > David Shrader > Master Consultant, Inc. > dshrader@master-consultant.com > http://www.EyeForTheFuture.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 03: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 DAA16628 for ; Tue, 7 Nov 2000 03:01:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0599C44366; Tue, 7 Nov 2000 01:59:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 759CD44337 for ; Tue, 7 Nov 2000 01:58:07 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA10222; Tue, 7 Nov 2000 03:00:20 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPTA>; Tue, 7 Nov 2000 02:56:39 -0500 Message-ID: From: Jonathan Rosenberg To: "'William Marshall'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: Pre-loaded Route headers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 02:56:34 -0500 Comments below. > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, November 03, 2000 4:02 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Re: Pre-loaded Route headers > > > I believe there may be a problem with Pre-loaded Route headers and > stateless proxies, but it not a difficult one to solve. But there > are side-affects that are not nice. > > An initial INVITE is normally the one that accumulates the > Record-Route > values; then they are stored at the UAS and converted into a > Route header > for UAS->UAC transactions, and echoed back to the UAC in the 200-OK so > the UAC converts them into a Route header for UAC->UAS transactions. > A mid-call INVITE (or any other message) contains the Route header > value, but doesn't need to accumulate Record-Routes again. > > But a stateless proxy can't really tell the difference between an > initial INVITE for a new session (one in which it should add itself > to the Record-Route) and a mid-call INVITE for an existing session (in > which it doesn't need to add itself). So it has two choices: > 1) always > add itself to a Record-Route, or 2) note there is a Route header and > assume therefore it is a mid-call message and do nothing. > > Keying on the existence of a Route header to indicate a mid-call > message isn't explicitely disallowed by the spec (unless I missed > it somewhere), but it would work just fine - until a UAC tried to > use a pre-loaded Route header. Then the proxy wouldn't get itself > into the Record-Route when it should. > > So the solution is to have the proxy insert itself into the > Record-Route header *independent of whether it is an initial INVITE > or a mid-call INVITE*. > > Unfortunately there is a backward compatibility problem here - a proxy > that doesn't know to do this for a mid-call message will be dropped > from future messages. If even one proxy along the path inserts a > Record-Route header on the mid-call message, the UAS and UAC will > trigger their Route re-calculation. (Presumably if none of > the proxies > did the Record-Route for a mid-call message, the UAC and UAS would > act like currently, and keep the Route from the initial INVITE). We had an extensive discussion on the list on just this topic. The result of that discussion is already in the bis draft: -- The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. A proxy SHOULD add it to anyrequestfor robustness, but a request route, once established, persists until the end of the call leg, regardless of whether the Record-Route header is present in subsequent requests. -- So, what this is saying is that a proxy should always insert the record-route, but a UA doesn't reload the record-routes if it has a set already. This avoids the backwards compatibility issue. But, you ask, what is the point of re-inserting them? THe answer is twofold. First, the original idea is recovery from crash and restarts. The restarted UA wouldn't have a record of the Record-Routes, and so when it gets a re-INVITE (via session timer, perhaps), it will re-establish the route based on the record-routes in the INVITE. Secondly, we have our recent discussion of sending invites with loaded routes. If proxies follow the above recommendation, they will always record-route, and the result is that the initial forced route will actually get persisted, since the UAS has no memory of a route when the initial request arrives. So, what we need here is a little motivational text so people notice this subtelty and implement it correctly, along with a reccomendation that proxies SHOULD NOT consider a request with a Route header as indicative of a mid-call or mid-session message. -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 Nov 7 03:06:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19096 for ; Tue, 7 Nov 2000 03:06:58 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EEC2A4437B; Tue, 7 Nov 2000 02:00:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3FC264437A for ; Tue, 7 Nov 2000 01:59:32 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA10230; Tue, 7 Nov 2000 03:01:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPTC>; Tue, 7 Nov 2000 02:57:59 -0500 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , SIP@lists.bell-labs.com Subject: RE: [SIP] Media to send 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, 7 Nov 2000 02:57:55 -0500 The text is generic, and not specific to SDP. SDP has no way to indicate separate send and receive codecs for the same 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: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Friday, November 03, 2000 6:50 PM > To: SIP@lists.bell-labs.com > Subject: [SIP] Media to send > > > 2543bis 4.2.1 INVITE: > > "The INVITE method indicates that the user or service is > being invited > to participate in a session. The message body MAY contain a > description of the session to which the callee is being > invited. For > two-party calls, the caller indicates the type of media it > is able to > receive and possibly the media it is willing to send as > well as their > parameters such as network destination. A success response MUST > indicate in its message body which media the callee wishes > to receive > and MAY indicate the media the callee is going to send." > > How does a UA indicate (in case it wishes) the media it is > going to send? > > Uri > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 7 03: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 DAA22155 for ; Tue, 7 Nov 2000 03:14:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6261844369; Tue, 7 Nov 2000 02:04:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id F353D44337 for ; Tue, 7 Nov 2000 02:03:07 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA10243; Tue, 7 Nov 2000 03:05:20 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPTF>; Tue, 7 Nov 2000 03:01:39 -0500 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] SIP negotiation 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, 7 Nov 2000 03:01:37 -0500 > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Friday, November 03, 2000 2:25 PM > To: sip@lists.bell-labs.com > Subject: [SIP] SIP negotiation > > > Sorry for the basic question.. but: > > How can two SIP end points negotiate QoS, Bandwidth, vocoders > ? QoS, bandwidth, and other media stream reservations are handled via QoS reservation protocols like RSVP. The relationship with SIP signaling is loose. Worst case, there is a temporal correlation in the two. For more info, check out the famed "manyfolks" draft: http://search.ietf.org/internet-drafts/draft-manyfolks-sip-resource-01.txt As for codecs, its part of the standard SDP usage defined in the appendix B to RFC2543. -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 Nov 7 03: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 SMTP id DAA24900 for ; Tue, 7 Nov 2000 03:20:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1E1244388; Tue, 7 Nov 2000 02:07:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 995E044388 for ; Tue, 7 Nov 2000 02:06:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA10251; Tue, 7 Nov 2000 03:09:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPTH>; Tue, 7 Nov 2000 03:05:29 -0500 Message-ID: From: Jonathan Rosenberg To: "'Agarwal, Aseem'" , "'SIP List'" Cc: Jonathan Rosenberg Subject: RE: [SIP] Sip- Message OPTION 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, 7 Nov 2000 03:05:24 -0500 > -----Original Message----- > From: Agarwal, Aseem [mailto:aseem@trillium.com] > Sent: Friday, November 03, 2000 1:20 PM > To: 'SIP List' > Cc: 'Jonathan Rosenberg' > Subject: RE: [SIP] Sip- Message OPTION > > > Hi Jonathan, > The draft (bis-2 section 4.2.3) says: > "The response MAY contain a message body indicating the capabilities > of the end system ..." > > This gives an idea that OPTIONS should be relevant only for a UAS, > since only a UAS can respond with the capabilities of the logged in > users. The example given in section 16.8, also seems to suggest the > same. > However, theoretically, it is possible for a user to register > his media capabilities as well in the REGISTER message with the > Registrar. But I see this as a more dynamic thing which can > potentially change from a call to call. So, what is the usage of > supporting OPTIONS at a Registrar server ? Kindly clarify. That is not usage for a registrar. A SIP request addressed to a registrar (sip:dynamicsoft.com) would not contain SDP in the response. A SIP request addressed to an end user (sip:jdrosen@dynamicsoft.com) would possibly contain SDP in the response. I will clarify in the spec. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 03:26:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27697 for ; Tue, 7 Nov 2000 03:26:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA0084438E; Tue, 7 Nov 2000 02:11:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4A0184438C for ; Tue, 7 Nov 2000 02:10:28 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA10255; Tue, 7 Nov 2000 03:12:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPT2>; Tue, 7 Nov 2000 03:08:59 -0500 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , Sip List Subject: RE: [SIP] UAC Record Routing in draft-ietf-sip-call-flows-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 03:08:52 -0500 > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Friday, November 03, 2000 8:34 AM > To: Sip List > Subject: [SIP] UAC Record Routing in draft-ietf-sip-call-flows-01.txt > > > The way the UAC builds the Route on a final 200 response > in 3.1.2 of the call flows draft doesn't look quite > right ... > > 3.1.2 Successful SIP to SIP through two proxies > > User A Proxy 1 Proxy 2 User B > | | | | > | INVITE F1 | | | > |--------------->| | | > | 407 F2 | | | > |<---------------| | | > | ACK F3 | | | > |--------------->| | | > | INVITE F4 | | | > |--------------->| INVITE F5 | | > | (100) F6 |--------------->| INVITE F7 | > |<---------------| (100) F8 |--------------->| > | |<---------------| | > | | | 180 F9 | > | | 180 F10 |<---------------| > | 180 F11 |<---------------| | > |<---------------| | 200 F12 | > | | 200 F13 |<---------------| > | 200 F14 |<---------------| | > |<---------------| | | > | ACK F15 | | | > |--------------->| ACK F16 | | > | |--------------->| ACK F17 | > | | |--------------->| > > F14 200 OK Proxy 1 -> A > > SIP/2.0 200 OK > Via: SIP/2.0/UDP here.com:5060 > Record-Route: , > > From: BigGuy > To: LittleGuy ;tag=314159 > Call-ID: 12345601@here.com > CSeq: 1 INVITE > Contact: LittleGuy > Content-Type: application/sdp > Content-Length: 134 > > v=0 > o=UserB 2890844527 2890844527 IN IP4 there.com > s=Session SDP > c=IN IP4 110.111.112.113 > t=0 0 > m=audio 3456 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > > > F15 ACK A -> Proxy 1 > > ACK sip:UserB@there.com SIP/2.0 > Via: SIP/2.0/UDP here.com:5060 > Route: , > > From: BigGuy > To: LittleGuy ;tag=314159 > Call-ID: 12345601@here.com > CSeq: 1 ACK > Content-Length: 0 > > The UAC should build the Route header in the ACK by > copying the 200 response Record-Route header, > reversing the order and then adding the Contact as > the last entry. (Note the 1st entry in the Route is > subsequently removed when the client actually sends F15). > But in this case the last entry has become an IP address. > Shouldn't the UAC just copy the Contact and not try > and do any resolution of it? Correct. This behavior is really bad, actually. It depends on being able to perform a resolution of the Contact address outside of the realm where it is supposed to be resolved. If there is a private DNS running, or some kind of local information is placed in the hostname, this resolution will fail at the called party. Alan - can you please fix? Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 03:31: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 DAA29767 for ; Tue, 7 Nov 2000 03:31:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7482D44386; Tue, 7 Nov 2000 02:21:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CF72F44382 for ; Tue, 7 Nov 2000 02:21:00 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA10300; Tue, 7 Nov 2000 03:22:51 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPTT>; Tue, 7 Nov 2000 03:19:10 -0500 Message-ID: From: Jonathan Rosenberg To: "'Piotr S. Kossowski'" , SIP discussion list Subject: RE: [SIP] Errors handling on session description in ACK 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, 7 Nov 2000 03:19:09 -0500 > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Wednesday, November 01, 2000 7:27 AM > To: SIP discussion list > Subject: [SIP] Errors handling on session description in ACK > > > Hello, > > When UAC send session description in INVITE request, UAS send 200 OK > if it supports them or 606 Not Acceptable if not. Clear. > (I assume ideal situation: no 1xx, etc.) > > When UAC doesn't send session description in INVITE (what means > that it's going to do that in ACK), UAS' 200 OK contains description. > Next, UAC sees that it will not be able to support capabilities > of UAS. Does it send session descr. as if it would send in INVITE, > regardless of this failed handshake ? This scenario will fail, > because there is no way of negotiation after UAC has sent ACK, > since ACK doesn't generate response. The ACK has an empty body, and the UAC sends a BYE right away. > > > More generaly: > 1. When UAC has an error and doesn't send session descr. in ACK ( > INVITE did NOT contain session descr. as well), Should > UAS just ignore such ACK and treat it as *not received* ? It should stop retransmitting the 200 OK. That aside, there are no media sessions. > > 2. Should garbage in body of type application/sdp generate > 4xx response (which one ?) or 606 with appropriate code in > Warning header (which one ?) 4xx, since the request is malformed. Which one? Plain old 400 is probably fine. > > > By the way, > > I've compared bis-02 with draft-ietf-mmusic-sip-new-00.ps > (August '99). Why? The only useful thing for comparison is rfc2543. > > Section 10.5.1 Unreliable Transport Protocols (bis-02): > > "(...)Response retransmissions cease when (...) the response has been > RETRANSMITTED seven times." > > Section 10.5.1 (draft-ietf-mmusic-sip-new-00.ps): > > "(...)Response retransmissions cease when (...) the response has been > TRANSMITTED seven times." RFC2543 also says transmitted seven times. I think it should still be transmitted, not retransmitted. 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: (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 Nov 7 03: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 DAA02588 for ; Tue, 7 Nov 2000 03:38:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31A9E4437A; Tue, 7 Nov 2000 02:31:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DDB714436E for ; Tue, 7 Nov 2000 02:30:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA10333; Tue, 7 Nov 2000 03:33:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YPT6>; Tue, 7 Nov 2000 03:29:29 -0500 Message-ID: From: Jonathan Rosenberg To: "'Jean-Francois Mule'" , "'archow@hss.hns.com '" , "'sip@lists.bell-labs.com '" Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 03:29:22 -0500 > -----Original Message----- > From: Jean-Francois Mule [mailto:jfmule@clarent.com] > Sent: Tuesday, October 31, 2000 12:46 AM > To: 'archow@hss.hns.com '; 'sip@lists.bell-labs.com ' > Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax > cal ls - Internet Draft) > > > Arjun: > Thanks for your comments. > For the proxy, the 2 call legs constitute 2 distinct SIP > transactions so > there is no particular reason to propagate the CSeq number > from one call leg > to the other. No. The call flow is a very standard re-INVITE type of thing. There is no reason why this proxy should behave any differently from any other proxy. Proxies do not modify CSeq. Period. There is no reason why this cannot be a standard flow, and for purposes of interoperability, it should be. The flow you have in the document is not compliant to the spec. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 03:47:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06484 for ; Tue, 7 Nov 2000 03:47:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1D1044359; Tue, 7 Nov 2000 02:44:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id CB72644356 for ; Tue, 7 Nov 2000 02:43:19 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id CAA09102; Tue, 7 Nov 2000 02:43:11 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eA78f8k20097; Tue, 7 Nov 2000 02:41:08 -0600 (CST) Received: from ericsson.com (kipe51.eraj.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id CAA18571; Tue, 7 Nov 2000 02:43:09 -0600 (CST) Message-ID: <3A07C09B.DAC8B5E5@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Neil Deason'" , "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: Re: [SIP] Identification 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 07 Nov 2000 09:43:07 +0100 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > >I like this approach except I would take it a step further and > >do this for all URLs including SIP URLs. This allows maddr to go > >back to its original intention for SIP URLs. Plus I hate special > >cases; this seems (nominally) easier to implement. > > Conceptually that is clearly the better way. However, there is a backwards > compatibility problem. Older rfc2543 implementations will use the maddr to > forward (if they are working correctly, that is), but not an address > parameter of the Route header. This seems to be a backwards compatibility we can afford to break. Will an older rfc2543 implementation really work with one based on bis anyways? There seem to have been some substantial changes in the mechanisms. At the very least, there is a syntactic change. (I had to play this card because I believe implementations should handle this change -- the addition of RR parameters) /sean > > -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 Nov 7 03:51: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 DAA08174 for ; Tue, 7 Nov 2000 03:51:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4181D44382; Tue, 7 Nov 2000 02:47:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6AAFA44373 for ; Tue, 7 Nov 2000 02:46:38 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA10378; Tue, 7 Nov 2000 03:48:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YP4G>; Tue, 7 Nov 2000 03:45:09 -0500 Message-ID: From: Jonathan Rosenberg To: Kevin Lingle Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Some brief comments on the SIP MIB 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, 7 Nov 2000 03:45:09 -0500 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgschul@attglobal.net] > Sent: Sunday, October 29, 2000 8:30 AM > To: Kevin Lingle > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Some brief comments on the SIP MIB > > > > > > > - ULS should probably at least mention LDAP as an example. > > > > ULS has undergone some changes. We had a request to handle > prioritzed > > backup addressess. I also got some comments that having one generic > > ULS address wasn't sufficient. Systems may have multiple > resources they > > use to determine where users are. > > > > You can view the proposal on sip-mib@egroups.com archive > > [http://www.egroups.com/message/sip-mib/40]. There has been no > > feedback on the proposal yet (unfortunately that is typical). > > I would appreciate if you could take a quick look. Btw, the > > current proposal does not actualy handle prioritized addresses > > correctly (i need to consider that further). What is your view > > on having the ability to specify backup addresses ULS? > > Probably needs discussion by those building proxies, as I can > primarily > speak from our own experience. In our server, locations are > derived from > several different sources > > - LDAP > - an SQL database for registrations > - a set of user-configurable scripts that provide mappings > from SIP user > ids to other user id's, e.g., resolution of email aliases. > > While being able to change the LDAP URL via the management console is > useful, I doubt that describing or changing the others is particularly > helpful (and not likely to be feasible, given that just > connecting to a > different SQL server just doesn't magically make the table definitions > appear there). I think the notion of generalzied, configurable ULS through SNMP is fundamentally a hopeless cause. THe problem is that a location service is an abstract concept. It can be the result of program execution, LDAP queries, SQL queries, ENUM, finger, whois, local files, IVR interaction, etc. Your assumption is that in all cases there is at least an IP address that indicates where the service is. I don't think thats generally true. Certain location services (local file, IVR interaction, program execution), don't really have such a concept. So, there are two choices. Either completely drop this ULS thing, or restrict it to a specific set of known location services which do have a common set of configuration information. Access to an external database is probably pretty broad but has a common set of information that you could configure (IP address, username and password for access, port, transport, database instance name) -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 Nov 7 03:54: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 DAA09479 for ; Tue, 7 Nov 2000 03:54:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E913B44396; Tue, 7 Nov 2000 02:50:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2DD7344356 for ; Tue, 7 Nov 2000 02:49:54 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA10383; Tue, 7 Nov 2000 03:51:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YP4H>; Tue, 7 Nov 2000 03:48:09 -0500 Message-ID: From: Jonathan Rosenberg To: "'Hisham Khartabil'" , Bertil Engelholm , SIP@lists.bell-labs.com Cc: Jonathan Rosenberg Subject: RE: [SIP] multiple responses ?? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 03:48:01 -0500 Hisham is correct on both counts. -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: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > Sent: Wednesday, October 25, 2000 2:10 AM > To: Bertil Engelholm; SIP@lists.bell-labs.com > Cc: Jonathan Rosenberg > Subject: RE: [SIP] multiple responses ?? > > > > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Bertil Engelholm > > Sent: 24. lokakuuta 2000 13:41 > > To: SIP@lists.bell-labs.com > > Cc: Jonathan Rosenberg > > Subject: Re: [SIP] multiple responses ?? > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Bertil Engelholm [mailto:Bertil.Engelholm@uab.ericsson.se] > > > > Sent: Monday, October 23, 2000 12:20 PM > > > > To: sip@lists.bell-labs.com > > > > Subject: [SIP] multiple responses ?? > > > > > > > > > > > > Hi, > > > > > > > > I have some questions regarding the possibility to forward > > > > best vs. forward all responses. > > > > > > Forward all simply does not work. > > > > > > A proxy can forward one or more 200 responses (and > indeed, really must > > > forward all of them), since those are ACKed end to end. > > Non-200s are ACKed > > > hop by hop. A proxy or client receiving multiple non-200 > > responses to the > > > same request will have no way to distinguish them, and the > > state machines > > > currently defined would not work. > > > > OK, that simplifies things a bit. > > > > > > > > > > > > > First of all I wonder if this is not a function that should > > > > be decided by the UA e.g. by setting a special header ? > > > > > > Caller preferences addresses some simple cases where a > UAC can request > > > specific service from proxies. But, since > forward-all-responses doesn't > > > work, having a caller prefs value for it doesn't seem that useful. > > > > Maybe I used the wrong term here. Forward all seems not allowed > > as you explained above. But there are still two different > behaviours. > > Either the proxy only forwards the best response or it forwards > > all 200 responses. The problem I see is that a UA don't know if > > it's going to receive one or several 200 responses. So it has > > to be prepared to always receive several 200 responses. If you > > MUST set a header to get all 200 responses instead of only the > > best a UA can decide that it will not handle that case (by not > > setting the header). > > You must not set any header. You will get all 200 responses. > If you don't > want to accept the second one, ACK it then send a BYE (then > wait for 200OK > for BYE) > > > > > > > > > > > > It's the UA (the User) that knows if he like to get all > > > > responses and choose himself or let the network choose the > > > > best response. Why should each server take this decision ? > > > > > > We did it this way (forwarding only the best response) so > that it would > > > scale and work in a reasonable fashion. > > > > > > > > > > > Secondly I have a question regarding the proxy behaviour in > > > > the following case. > > > > > > > > ------ ------ > > > > | |----->| P2 |---->???? > > > > ------ | | ------ > > > > | Ca |----->| P1 | > > > > ------ | | ------ > > > > | |----->| P3 |---->???? > > > > ------ ------ > > > > > > > > If Ca calls someone at P1 which forks the call to P2 and P3 how > > > > should P1 behave in the following cases if it has the policy to > > > > fork the best response. > > > > > > > > If P2 (or someone behind P2) have the policy to fork > all responses > > > > it means that P1 can get several final responses. > > > > > > Only multiple 200. > > > > > > > Which of these > > > > reponses should be used in the best choice by P1 ? > > > > Only the first one that happens to arrive ? > > > > Everyone that arrives before you get a response from P3 ? > > > > > > Beyond 200s, picking which is the best of the non-200 responses > > is defined > > > by the spec (600, then 300, then 400, then 500 in that order). > > However, a > > > proxy could choose an alternate definition of best amongst the > > non-200 final > > > responses it gets, since there are no interoperability issues > > which choosing > > > an alternate algorithm. > > > > > > > > > > > What should be done with the rest of the responses that > might drop > > > > in after you have sent your best response back ? > > > > > > There should only ever be 200s, which are forwarded upstream. > > Anything else > > > would be an error. > > > > > > > > > > > You could actually have received an ACK back from Ca > when another > > > > response drops in from P2. What to do in this case ? > > > > > > Won't happen under correct operating conditions. > > > > I'm not shure I understand why this can't happen. If P2 > > can send several 200 responses back to P1 I guess they can > > come at any time (depending on when someone answers at the > > other end). So lets say that the first 200 that is received > > from P2 is choosen as the best result and sent back to Ca. > > Ca now ACK this OK to P1 because Ca don't know it will > > get more 200 responses later on. P1 sends the ACK to P2. Another > > UA behind P2 somewhere now answers the same call which leads > > to a second 200 response from P2 to P1. And this second > > 200 response will belong to another CALL-LEG since the TO-tag > > is different. Maybe I have misunderstood something completly > > but this is how we have read the specification. If this > > can't happen it would simplify things but I don't understand > > why it can't happen. > > This can happen. You do exactly what i described above. > > Regards, > Hisham > > > > > > > > > -Jonathan R. > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Bertil Engelholm > > AXE Research and Development voice : +46 8 727 3499 > > SIP Security Fax : +46 8 647 8276 > > S-126 25 Stockholm Sweden E-mail: > > Bertil.Engelholm@uab.ericsson.se > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 06:36:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16668 for ; Tue, 7 Nov 2000 06:36:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 554D94433D; Tue, 7 Nov 2000 05:36:06 -0500 (EST) 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 C14B644337 for ; Tue, 7 Nov 2000 05:35:33 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 7 Nov 2000 11:35:28 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA26705; Tue, 7 Nov 2000 12:33:47 +0100 (BST) From: "Jo Hornsby" To: "Drage, Keith (Keith)" , "'james jack'" , "SIP@lists.bell-labs.com" , "'Jonathan Rosenberg'" Subject: RE: [SIP] discussion Message-ID: <000801c048ae$9749f610$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: <475FF955A05DD411980D00508B6D5FB00BD014@en0033exch001u.uk.lucent.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 11:33:46 -0000 Content-Transfer-Encoding: 7bit > Some minor tweaks to the original proposal, with the aim of > aligning all the text into a common format, and ensuring that > we have a clearly specified set of sender and receiver > requirements, and not with any aim of technically changing it.. > > > The header fields required, optional, and not applicable for each method > > are listed in Table 4 and Table 5. The table uses "o" to indicate > > optional, "m" mandatory and "-" for not applicable. > > > "Optional" means that a UAC \MAY include the header in a request, > and a UAS \MAY ignore the header if present in the request. Similarly, an > optional response header implies that a UAS \MAY place the header in a > response, and the UAC \MAY ignore the header if present in a response it > receives. Immediately, Require springs to mind; surely a UAS MUST take notice of Require? What about Record-Route, or Accept? While it seems appropriate to identify UAC behaviour with Requests, and UAS behaviour with Responses, I am not sure that it can be taken much further except on a header-by-header basis. > "Mandatory" means the UAC \MUST include the header in a request, and > a UAS \MUST understand the header if present in a request it receives. > Similarly, a mandatory response header implies that a UAS \MUST place the > header in a response, and the UAC \MUST understand the header if > present in > a response it receives. [...] - Jo. -- Jo Hornsby; IT Professional -- mailto:jhornsby@ubiquity.net Ubiquity Software Corporation -- http://www.ubiquity.net/ Hi, Chris! &:) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 07:15: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 HAA02235 for ; Tue, 7 Nov 2000 07:15:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4EFFB4433D; Tue, 7 Nov 2000 06:15:08 -0500 (EST) 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 2CDF244337 for ; Tue, 7 Nov 2000 06:14:31 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 7 Nov 2000 12:14:25 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA11702; Tue, 7 Nov 2000 13:12:38 +0100 (BST) From: "Jo Hornsby" To: "Billy Biggs" , "Agarwal, Aseem" Cc: "Sip List" Subject: RE: [SIP] Handling of unknown SIP methods and headers Message-ID: <000a01c048b4$05299be0$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: <20001102000915.C1402@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 7 Nov 2000 12:12:38 -0000 Content-Transfer-Encoding: 7bit > Agarwal, Aseem (aseem@trillium.com): > > > Pardon me if this has already been discussed earlier, but can > > somebody verify the following behavior : > > You are almost correct. I think your table is slightly misleading. > > > 1. Unknown method > > Trans - Stateful proxy: Forward if possible, else 405/501 > > Call - stateful proxy: Forward if possible, else 405/501 > > A proxy should proxy the request. Only if the request is destined for > the proxy (the Request-URI was 'sip:my.proxy.com') should the proxy > return a 501. > > > Redirect server: Return 405/501 > > Again, if the request is destined for a user of the redirect server, > the server should happily return a 300-class response to the unknown > request. It should only return a 501 if the request was destined for > the redirect server (the Request-URI was 'sip:my.redirect.com') and the > server didn't understand it. [...] Just a small nit: I would argue 405 for something like 'sip:my.proxy.com' (the proxy does understand the method, it just doesn't like it for this Request-URI). 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 Nov 7 07:46:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17089 for ; Tue, 7 Nov 2000 07:46:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F420044355; Tue, 7 Nov 2000 06:46:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CF9F544337 for ; Tue, 7 Nov 2000 06:45:56 -0500 (EST) Received: from dynamicsoft.com (ip118.honxr1.ras.tele.dk [195.249.119.118]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA10926; Tue, 7 Nov 2000 07:48:07 -0500 (EST) Message-ID: <3A07F989.9C6BF571@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Fairlie-Cuninghame, Robert'" , sip@lists.bell-labs.com Subject: Re: [SIP] OPTIONS and out-of-band Route. 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, 07 Nov 2000 13:46:01 +0100 Content-Transfer-Encoding: 7bit I wonder if it might be troublesome to start record-routing on any messages exchanged prior to an intial INVITE as this will often be what service logic triggers on. The service logic and management of the triggers might become more complex and more brittle if one has to be ready to start record-routing on a wider variety of conditions. Anders Kristensen Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > Sent: Monday, November 06, 2000 10:53 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] OPTIONS and out-of-band Route. > > > > > > > > There's seems to be a lot of discussion lately about out-of > > band Route in > > INVITE. Here's a another reason for correct processing of > > "out-of-band" > > Route headers ("out-of-band" with respect to an INVITE > > initiated call-leg): > > > > When a UAC makes a OPTIONS request before performing a full > > INVITE, the UAS > > may include a Contact in the 200 OK which be used as the > > direct destination > > to send the initial INVITE. If a proxy needs to be on the path of the > > initial INVITE (eg proxy is acting as ALG) then the call will > > fail if the > > proxy and UAC doesn't take some additional action. > > > > DOn't we need to add something such as the following to the spec? > > Well, this is a symptom of a more general problem, which is what is the > meaning of Record-Routing in requests in general, beyond INVITE. I would > propose the following: > > If a proxy inserts a record-route into a request, that means it wishes to > receive all subsequent requests, in both directions, that contain the same > value of the To, From, and Call-ID. > > I like this, since then it works for MESSAGE and SUBSCRIBE, which have > similar requirements. > > Now, to handle your OPTIONS case: > > If a UAC initiates a call to a host as the result of an OPTIONS query, it > SHOULD use the same Call-ID as was used in the OPTIONS query. Note that as a > result of standard Record-Routing rules, this INVITE will contain any > routing information learned from the OPTIONS response. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 09:30:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28372 for ; Tue, 7 Nov 2000 09:30:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 330094433D; Tue, 7 Nov 2000 08:30:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id D77CA44337 for ; Tue, 7 Nov 2000 08:29:37 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA28332; Tue, 7 Nov 2000 09:29:12 -0500 (EST) Message-ID: <3A0811B9.13381927@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Piotr S. Kossowski'" , SIP discussion list Subject: Re: [SIP] Errors handling on session description in ACK 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, 07 Nov 2000 09:29:13 -0500 Content-Transfer-Encoding: 7bit > > > > Section 10.5.1 Unreliable Transport Protocols (bis-02): > > > > "(...)Response retransmissions cease when (...) the response has been > > RETRANSMITTED seven times." > > > > Section 10.5.1 (draft-ietf-mmusic-sip-new-00.ps): > > > > "(...)Response retransmissions cease when (...) the response has been > > TRANSMITTED seven times." > > RFC2543 also says transmitted seven times. > > I think it should still be transmitted, not retransmitted. Changed to "transmitted". -- 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 Nov 7 09:46:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05715 for ; Tue, 7 Nov 2000 09:46:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6034644359; Tue, 7 Nov 2000 08:46:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E18AC44337 for ; Tue, 7 Nov 2000 08:45:11 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA29203; Tue, 7 Nov 2000 09:44:56 -0500 (EST) Message-ID: <3A081569.CB53C201@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'David Shrader'" , SIP List Subject: Re: [SIP] rfc2543bis comment/question 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, 07 Nov 2000 09:44:57 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I think this note is simply wrong. I don't even remember noticing it until > you pointed it out. Its in both bis and rfc2543. It should be stricken. > > Henning - do you agree? Yes, it's gone now. It appeared in draft-ietf-mmusic-sip-09.txt, but without explanation. -- 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 Nov 7 09:49:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07193 for ; Tue, 7 Nov 2000 09:49:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 68B6244364; Tue, 7 Nov 2000 08:49:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 03AA544337 for ; Tue, 7 Nov 2000 08:48:20 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id GAA16075 for ; Tue, 7 Nov 2000 06:43:55 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SIP] OPTIONS and out-of-band Route. From: David Shrader To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 07 Nov 2000 09:39:48 -0500 Content-Transfer-Encoding: 7bit I agree. Since the Record-Route mechanism is predicated on the fact that the proxy wants to remain in the call path because it is going to maintain state on the call, it is extremely problematic if the record-route function occurs on an OPTIONS. This would then, somehow, add pre-call-state prior to INVITE. Suppose conditions change between the OPTIONS and the INVITE, such as time-of-day routing decisions that cause the INVITE to routed a different way. Are we then stuck because we had a pre-loaded Route header that identifies a particular path? I think we can generalize the record-route mechanism to operate on the SUBSCRIBE/NOTIFY/MESSAGE type of requests, but I am concerned about pre-loading the Route on an initial INVITE (or initial SUBSCRIBE). David ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com > From: "Fairlie-Cuninghame, Robert" > Date: Mon, 6 Nov 2000 23:28:08 -0800 > To: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com > Subject: RE: [SIP] OPTIONS and out-of-band Route. > >> >> If a proxy inserts a record-route into a request, that means >> it wishes to >> receive all subsequent requests, in both directions, that >> contain the same >> value of the To, From, and Call-ID. >> >> I like this, since then it works for MESSAGE and SUBSCRIBE, which have >> similar requirements. > > Agreed. Much more general. > >> Now, to handle your OPTIONS case: >> >> If a UAC initiates a call to a host as the result of an >> OPTIONS query, it >> SHOULD use the same Call-ID as was used in the OPTIONS query. >> Note that as a >> result of standard Record-Routing rules, this INVITE will contain any >> routing information learned from the OPTIONS response. >> > My only comment here is that Section 11 & 12 on the behavior of UAC's and > proxies is written from the point of view that a Call State Machine is > created by an "initial INVITE request". I believe it is this idea, that is, > importing "out-of-band" Route information from _before_ the Initial INVITE > Request, that is cause of the recent discussions/queries/confusion in this > area. In other words, in my mind the existing Record-Route rules description > doesn't quite stretch to unambiguously cover the pre-initial-invite > behaviour. I think a small clarification would be helpful. > > Cheers, > > Robert. > > -- My opinions are my own. I tried selling them once but everybody > seems to already have one. -- > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 7 10:00: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 KAA12397 for ; Tue, 7 Nov 2000 10:00:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB10144340; Tue, 7 Nov 2000 09:00:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id 6F44644337 for ; Tue, 7 Nov 2000 08:59:12 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 984814CE59; Tue, 7 Nov 2000 09:59:06 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA12986; Tue, 7 Nov 2000 09:59:05 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id JAA36153; Tue, 7 Nov 2000 09:59:05 -0500 (EST) Message-Id: <200011071459.JAA36153@fish-ha.research.att.com> Subject: RE: [SIP] Re: Pre-loaded Route headers To: jdrosen@dynamicsoft.com, sip@lists.bell-labs.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, 7 Nov 2000 09:59:05 -0500 (EST) There is informative text at the beginning of 6.34.1, and also informative text in 6.34.2. However, they contradict each other. There is no normative text for this situation at all. See, for example, lines 3-4 of 6.34.2: A UA builds the Route header field for subsequent requests from the Record-Route header fields received in either a response or a request. I would take this to explicitely allow a mid-call change of Record-Route/Route values. What is needed is some normative text about the handling of Record-Route in UAC/UAS/Proxies. I believe the workable combination is: UAC: MUST convert the Record-Route to a Route on the final response to the first request of a call leg, and use it for all future requests with the same call-leg identification. MUST convert the Record-Route from a provisional response into a Route for use solely in a PRACK and COMET. (This requirement is from 100rel, and was copied into manyfolks, but I don't understand how it might be different than first case above - unless it intends to allow mid-call requests with provisional responses to take a different route.) MUST NOT update Route value based on any Record-Route received in a subsequent request/response with the same call-leg identification. UAS: MUST convert the Record-Route to a Route on the first request with a new call-leg identification. Within a single transaction, MUST include the value of Record-Route received in the request in every response that requests a PRACK. (Should this instead be to include the value of Record-Route received in the first request with the same call-leg identification, to remove the dependance on proxies doing the right thing?) MUST NOT update Route value based on any Record-Route received in a subsequent request/response with the same call-leg identification. Proxy: Either (1) MUST insert itself into the Record-Route header in every request for a particular call-leg identification, or (2) MUST NOT insert itself into any Record-Route header for a particular call-leg identification. (Note this is a SHOULD in case #1 in 2543bis) The proxy behavior is difficult for a stateless proxy, unless it makes the decision (to be in the Record-Route or not) independent of call-leg identification. I believe the above requirements have the property that, if the proxies do the right handling, the UAC/UAS can botch the handling and still be OK. Further, if the UAC/UAS do the right handling, the proxies can be wrong and everything will still work OK. Bill Marshall wtm@research.att.com -----original message----- From: Jonathan Rosenberg To: "'William Marshall'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: Pre-loaded Route headers Date: Tue, 7 Nov 2000 02:56:34 -0500 Comments below. > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, November 03, 2000 4:02 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Re: Pre-loaded Route headers > > > I believe there may be a problem with Pre-loaded Route headers and > stateless proxies, but it not a difficult one to solve. But there > are side-affects that are not nice. > > An initial INVITE is normally the one that accumulates the > Record-Route > values; then they are stored at the UAS and converted into a > Route header > for UAS->UAC transactions, and echoed back to the UAC in the 200-OK so > the UAC converts them into a Route header for UAC->UAS transactions. > A mid-call INVITE (or any other message) contains the Route header > value, but doesn't need to accumulate Record-Routes again. > > But a stateless proxy can't really tell the difference between an > initial INVITE for a new session (one in which it should add itself > to the Record-Route) and a mid-call INVITE for an existing session (in > which it doesn't need to add itself). So it has two choices: > 1) always > add itself to a Record-Route, or 2) note there is a Route header and > assume therefore it is a mid-call message and do nothing. > > Keying on the existence of a Route header to indicate a mid-call > message isn't explicitely disallowed by the spec (unless I missed > it somewhere), but it would work just fine - until a UAC tried to > use a pre-loaded Route header. Then the proxy wouldn't get itself > into the Record-Route when it should. > > So the solution is to have the proxy insert itself into the > Record-Route header *independent of whether it is an initial INVITE > or a mid-call INVITE*. > > Unfortunately there is a backward compatibility problem here - a proxy > that doesn't know to do this for a mid-call message will be dropped > from future messages. If even one proxy along the path inserts a > Record-Route header on the mid-call message, the UAS and UAC will > trigger their Route re-calculation. (Presumably if none of > the proxies > did the Record-Route for a mid-call message, the UAC and UAS would > act like currently, and keep the Route from the initial INVITE). We had an extensive discussion on the list on just this topic. The result of that discussion is already in the bis draft: -- The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. A proxy SHOULD add it to anyrequestfor robustness, but a request route, once established, persists until the end of the call leg, regardless of whether the Record-Route header is present in subsequent requests. -- So, what this is saying is that a proxy should always insert the record-route, but a UA doesn't reload the record-routes if it has a set already. This avoids the backwards compatibility issue. But, you ask, what is the point of re-inserting them? THe answer is twofold. First, the original idea is recovery from crash and restarts. The restarted UA wouldn't have a record of the Record-Routes, and so when it gets a re-INVITE (via session timer, perhaps), it will re-establish the route based on the record-routes in the INVITE. Secondly, we have our recent discussion of sending invites with loaded routes. If proxies follow the above recommendation, they will always record-route, and the result is that the initial forced route will actually get persisted, since the UAS has no memory of a route when the initial request arrives. So, what we need here is a little motivational text so people notice this subtelty and implement it correctly, along with a reccomendation that proxies SHOULD NOT consider a request with a Route header as indicative of a mid-call or mid-session message. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 10:18:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20565 for ; Tue, 7 Nov 2000 10:18:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C6D1F4433D; Tue, 7 Nov 2000 09:18:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 608F144337 for ; Tue, 7 Nov 2000 09:17:54 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA01371; Tue, 7 Nov 2000 10:17:44 -0500 (EST) Message-ID: <3A081D19.FAB392E7@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: David Shrader Cc: sip@lists.bell-labs.com Subject: Re: [SIP] OPTIONS and out-of-band Route. 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, 07 Nov 2000 10:17:45 -0500 Content-Transfer-Encoding: 7bit David Shrader wrote: > > I agree. Since the Record-Route mechanism is predicated on the fact that the > proxy wants to remain in the call path because it is going to maintain state > on the call, it is extremely problematic if the record-route function occurs > on an OPTIONS. This would then, somehow, add pre-call-state prior to INVITE. > Suppose conditions change between the OPTIONS and the INVITE, such as > time-of-day routing decisions that cause the INVITE to routed a different > way. Are we then stuck because we had a pre-loaded Route header that > identifies a particular path? > > I think we can generalize the record-route mechanism to operate on the > SUBSCRIBE/NOTIFY/MESSAGE type of requests, but I am concerned about > pre-loading the Route on an initial INVITE (or initial SUBSCRIBE). I don't understand this concern. The client presumably has a reason to do the routing; nobody forces it to insert Route headers. The proxy keeps no state of any kind, it just obeys the Route headers. Thus, I'm a bit lost as to why this inconveniences the proxy in any way. -- 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 Nov 7 10:26: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 KAA23880 for ; Tue, 7 Nov 2000 10:26:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB66344370; Tue, 7 Nov 2000 09:26:07 -0500 (EST) 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 F2C1744337 for ; Tue, 7 Nov 2000 09:25:21 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 7 Nov 2000 15:25:16 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA19405; Tue, 7 Nov 2000 16:23:41 +0100 (BST) From: "Jo Hornsby" To: "Billy Biggs" , "Henning Schulzrinne" Cc: "SIP List" Subject: RE: [SIP] My comments on bis-02 Message-ID: <001101c048ce$b5d34a80$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: <20001030224808.B31229@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 7 Nov 2000 15:23:41 -0000 Content-Transfer-Encoding: 7bit > 2. In 4.2.5, it is noted that CANCEL requests cannot have Route headers. > Why not? Are you assuming that CANCEL is only useful for an initial > request? This breaks since we need to be able to CANCEL a pending > REFER or other extension method which doesn't complete quickly, for > example. I doubt that the thinking here is CANCEL is only useful for an initial request, more that there is no need to specify a Route since proxies will always "know" which locations to cancel in turn; CANCEL is not forwarded like other requests, thus a Route is not necessary. - 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 Nov 7 11:33:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26866 for ; Tue, 7 Nov 2000 11:33:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 824AB4433D; Tue, 7 Nov 2000 10:33:06 -0500 (EST) 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 6D3B744337 for ; Tue, 7 Nov 2000 10:32:18 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 7 Nov 2000 16:32:12 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA11524; Tue, 7 Nov 2000 17:30:44 +0100 (BST) From: "Jo Hornsby" To: Message-ID: <001601c048d8$13c3f8c0$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] More Record-Route Joy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 7 Nov 2000 16:30:44 -0000 Content-Transfer-Encoding: 7bit Hi, I need debunking (or otherwise) &:) The wording in bis02 in 6.34.2 reads: "If a UAC finds a Record-Route header in a final 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." I think the fact that this only applies to the initial INVITE is being thrashed out at the moment, but there is another problem. For the ACK, surely the Record-Route should be ignored unless the response was 2xx, else things are going to go horribly wrong. This applies to the initial INVITE, as well as to re-INVITEs; further, it should also apply to the pre-initial-INVITEs (for want of a better term), "...where the server can expect the client to retry for the same Call-Id, as in 401 (Unauthorized) or 484 (Address Incomplete)." [last para of 6.34.1]. In the non-2xx final response cases, the ACK should be sent to the same place as the corresponding INVITE, with the same Request-URI (as specified by 10.5.1). Cheers, - 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 Tue Nov 7 11:47:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03889 for ; Tue, 7 Nov 2000 11:47:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D1D144349; Tue, 7 Nov 2000 10:47:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 0C5BD44337 for ; Tue, 7 Nov 2000 10:46:45 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id LAA24904; Tue, 7 Nov 2000 11:41:52 -0500 (EST) Message-ID: <3A0831ED.827C32D4@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] Error reporting using via header in UDP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 07 Nov 2000 11:46:37 -0500 Content-Transfer-Encoding: 7bit Hello! (Im going to sound like a lawyer again. Yech! :-)). Here is the passage from the RFC that I am trying to interpret. In section 1.4.3: If the client sent the request via unicast UDP, the response is sent to the address contained in the next Via header field (Section 6.46) of the response. I use the term client to refer to the originator of a message. My questions / assumptions are below: 1. The address in the first via header need not necessarily be the peer address that the server reads from the udp socket when it gets the message. Of course, it is in the client's best interest to use a meaningful address. 2. If the server reads a request that is badly formatted except for the via header, it can silently drop the message if it wants. In general, the server is just being nice by returning error messages for udp requests and is not obliged to do so. 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 0932 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 13:00: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 NAA02148 for ; Tue, 7 Nov 2000 13:00:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8FDBF4433B; Tue, 7 Nov 2000 12:00:08 -0500 (EST) 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 CE61C44337 for ; Tue, 7 Nov 2000 11:59:59 -0500 (EST) Received: (qmail 69634 invoked by uid 100); 7 Nov 2000 17:59:56 -0000 Message-ID: <20001107175956.69633.qmail@microappliances.com> From: shh@microappliances.com To: Jonathan Rosenberg Reply-To: shh@microappliances.com Cc: "'Neil Deason'" , Jonathan Rosenberg , "'Bertil Engelholm'" , SIP@lists.bell-labs.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: RE: [SIP] Identification problem Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 7 Nov 2000 17:59:56 -0000 Content-Transfer-Encoding: 8bit Quoting Jonathan Rosenberg : > The advantage here is that one could insert URL parameters into the > record-route, and get them back in the request URI. Not the prettiest way > to > go. We could, as an alternative, simply mandate the State header in the bis > draft, which would provide a cleaner solution. > So, the State header will be a comma separated list (or multiple state headers) of state ids one per Route Header. However as one Route header is removed before sending out the request, the corresponding State header is retained, only to be removed by the subsequent proxy if it proceses the next route header. In other words there should be n+1 State headers for n Route headers in the request. This correlation process can become tricky. Knowing whether the topmost State info is relevant to the proxy can be difficult. I would prefer to see this state info in the record route/route headers. Shiv > > > >I like this approach except I would take it a step further and > >do this for all URLs including SIP URLs. This allows maddr to go > >back to its original intention for SIP URLs. Plus I hate special > >cases; this seems (nominally) easier to implement. > > Conceptually that is clearly the better way. However, there is a backwards > compatibility problem. Older rfc2543 implementations will use the maddr to > forward (if they are working correctly, that is), but not an address > parameter of the Route header. > > -Jonathan R. > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 7 14:15: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 OAA26331 for ; Tue, 7 Nov 2000 14:15:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B21C4433C; Tue, 7 Nov 2000 13:14:07 -0500 (EST) 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 EDDD644337 for ; Tue, 7 Nov 2000 13:13:43 -0500 (EST) Received: (qmail 79437 invoked by uid 100); 7 Nov 2000 19:13:32 -0000 Message-ID: <20001107191332.79436.qmail@microappliances.com> From: shh@microappliances.com To: Jonathan Rosenberg Reply-To: shh@microappliances.com Cc: "'Neil Deason'" , Jonathan Rosenberg , "'Bertil Engelholm'" , SIP@lists.bell-labs.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: RE: [SIP] Identification problem Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 7 Nov 2000 19:13:32 -0000 Content-Transfer-Encoding: 8bit Quoting Jonathan Rosenberg : > as I pointed out, this causes everything from the Contact/From to be copied > into Route, EXCEPT port and maddr. How about if we say that the Route > contains the user:password@host portion of the Contact/From, and everything > else is copied from the Record-Route? THis would include unknown URL > parameters. > Are we not going out of the way to retain the Request URI to be the final destination. This has caused problems is various contexts. Also an assumption is being made in all cases is that the Request URI is routable. What if a proxy receives a request with a URI that is not routable by it. Consider an INVITE abc@pqr.stu.xyz.com. The proxy receiving this request may not be able to route this because zone pqr may not be resolvable by this proxy, however if this request is sent to stu.xyz.com it may be. I would like to see request URIs indicate intermediate hops. I think the Request URI should retain its flexible flavor. In another thread: >Now, an interesting thing to note here. Lets say in this failure case, it >was the called party that hung up. The proxy downstream from P2 (say, P3), >pops its top Route, and tries to forward it to P2. But, that maddr > (pointing >to P2), generates an ICMP error. So, it looks up the host portion of the >request URI in DNS and tries the SRV process from there. I will note that >this will only succeed if, and only if, *THE REQUEST URI ALWAYS REFERS TO >THE RESOUCE FOR WHOM THE REQUEST IS DESTINED*. Now, this relates to a >previous thread. The issue there was how a UAS would construct the Route >headers, and whether we should maintain this property that the R-URI always >refers to the entity for whom the request is targeted. I originally felt >this was critical, and was coming close to backing down. Now, it seems we >have another case to back up my original claim that maintaining this >property is important. I would like to find out why resort to the Request URI when you could do better by sending the request to the next 'Route' header. Are we going out of our way to preserve the Request URI? What if it is not routable. 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 Nov 7 17:20:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14588 for ; Tue, 7 Nov 2000 17:20:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DCB04433B; Tue, 7 Nov 2000 16:20:07 -0500 (EST) 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 41AF244337 for ; Tue, 7 Nov 2000 16:19:35 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24154 for ; Tue, 7 Nov 2000 17:19:23 -0500 (EST) 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 RAA12004 for ; Tue, 7 Nov 2000 17:19:24 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Nov 2000 17:18:41 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E9E1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" 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] Making draft-lennox-sip-reg-payload-01.txt a SIP WG item Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 7 Nov 2000 17:19:20 -0500 At the last meeting, there was discussion of making draft-lennox-sip-reg-payload-01.txt a SIP WG item. It was decided to take this discussion to the list. If you have a problem with making this draft a WG item, please say so now. Thanks Brian Joerg 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 Nov 7 23:03:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16484 for ; Tue, 7 Nov 2000 23:03:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B7C54433B; Tue, 7 Nov 2000 22:03:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 98C9144337 for ; Tue, 7 Nov 2000 22:02:19 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Nov 2000 20:02:55 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" Cc: SIP@lists.bell-labs.com Subject: RE: [SIP] Identification problem MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 20:02:48 -0800 > > Another potential solution is to slightly change the way > Route headers are > constructed. Right now, the spec says: > > ---- > 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. Since the URIs contained in the Record-Route > header fields are not useful for > the reverse request path, the UA fills all other components > of the Route > name-addr value with the name-addr > value found in the Contact or the From header field. The > latter is used only > if there is no Contact > header field. > ---- > > as I pointed out, this causes everything from the > Contact/From to be copied > into Route, EXCEPT port and maddr. How about if we say that the Route > contains the user:password@host portion of the Contact/From, > and everything > else is copied from the Record-Route? THis would include unknown URL > parameters. > > The advantage here is that one could insert URL parameters into the > record-route, and get them back in the request URI. Not the > prettiest way to > go. I was thinking along the same lines - I think this would solve a couple of problems. Firstly, I can't see it causing any backward-compatibility problems as any "other parameters" in the Request-URI (ie implementation specific Record-Route paramters) are simply going to be ignored by other proxies that may see the Request-URI. That is, no changes required anywhere except in the way the proxy builds its _own_ Record-Route entry - perfect. Secondly, this solves the stored Record-Route state problem (ie, the proxy never sees the information stored in the Route entry because it is overwritten ). This means that Record-Route-ing can be done statelessly - probably important in OPTIONS and other non-INVITE Record-Routing that don't have any BYE/Expire sequence to clean up the Route information. We should however define a standard Record-Route "branch"-like options names for implementation specific information - so we don't get clashes on Request-URI option names. However, a proxy which understands the new Route options should _only_ act upon the the route-state header _if_ it can identify that the header was created by itself. In furtherance of the above and in solving the maddr:port problem for non-sip URL's, then a proxy SHOULD also add a record-route address headers (and MUST do so if the proxy adds a rroute state header ). How about ....... Record-Route: [Request-URI];rr-host=host:port;rr-state=balhblahblah I've skipped a lot of details but I sure this is going to drawn enough discussion. [Eg, how can a proxy can tell if a UAS will scrub the record-route paaramters due to an older implementation?] 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 Wed Nov 8 03: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 SMTP id DAA28624 for ; Wed, 8 Nov 2000 03:55:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C8B24433B; Wed, 8 Nov 2000 02:55:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 7F03344337 for ; Wed, 8 Nov 2000 02:54:15 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V797L605; Wed, 8 Nov 2000 09:52:25 +0100 From: "Hisham Khartabil" 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.50.4133.2400 Subject: [SIP] SIP Extensions for Presence Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 8 Nov 2000 10:55:29 +0200 Content-Transfer-Encoding: 7bit Hi all, Apologies for the long email, but I have few questions regarding SIP Extensions for Presence. 3. Definitions "Presence User Agent (PUA): A Presence User Agent manipulates presence information for a presentity. In SIP terms, this means that a PUA generates REGISTER requests, conveying some kind of information about the presentity." "Presence Agent (PA): A presence agent is a SIP user agent which is capable of receiving SUBSCRIBE requests, responding to them, and generating notifications of changes in presence state." Q: what about the sip user agent that generates SUBSCRIBE request and receiving notifications? Should we have a definition for that? Are we assuming s/he is the SUBSCRIBER? 4.2 Message Flow ... "In fact, it is possible that two different presence clients register for the same presentity. In this case, the presence server, acting as a proxy, may fork the SUBSCRIBE, which means it sends multiple copies of the request, one to each presence client. Each client will presumably query its principal about whether the subscription is acceptable. In the common case where a principal has left their presence tool running at work, and then gone home and started the tool there, the principal will accept the subscription at home. This causes a success response to be generated, and forwarded to the presence server (which is acting as a proxy), and then back to the subscriber. The presence tool at home then assumes responsibility for that subscription. The tool at work can continue to support subscriptions it received previously." Since I am not at work, my status will not change so no notifications will be generated. This does not give the subscriber and up to date notification of my presence. Q: how about if I don't want my subscriptions at work to continue and I want them to be transferred home? I know this is achieved over time since SUBSCRIBE has Expires: header. But this could take hours (or one hour). There should be a way to transfer subscriptions. ... "As an optimization, notifications do not need to be sent if the subscriber is not actually online. This improves scalability." Q: is this assuming that A is subscribed to B and vice versa? Otherwise, who would a Presence Agent Know that the subscriber on offline? ... "A SUBSCRIBE request MUST contain a Contact header. This indicates the address(es) (as a SIP URL) to which the client would like to receive notifications. This MUST be be one or more SIP addresses, containing the fully qualified domain names for the host generating the subscription, or the IP address of the host generating the subscription. Other addresses are possible, supporting third party subscriptions. If it contains multiple addresses, notifications will be sent to each address. If no Contact header is present, no notifications will be sent." Q: since a SUBSCRIBE request MUST contain a Contact header, why wouldn't you respond with 4xx if no Contact is present? General Question: If a client sends a REGISTER or a SUBSCRIBE with Expires: 3600. The client then re-Registers or re-subscribe with Expires: 3600 again, but before the first one has expired (say 600 secs left). Does the new timer get reset to 3600 secs or 4200 secs (3600 + whatever is left from the first request. 600 in our case). Regards, Hisham 0=====================================================================0 o Hisham Khartabil - Hotsip Finland o o mailto:hisham.khartabil@hotsip.com o o sip: Hisham.khartabil@hotsip.com o o mobile: +358 40 582 7484 o o fax: +3589 856 642 10 o 0=====================================================================0 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 04:51:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22293 for ; Wed, 8 Nov 2000 04:51:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F42344349; Wed, 8 Nov 2000 03:51:06 -0500 (EST) 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 527F844337 for ; Wed, 8 Nov 2000 03:50:43 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Nov 2000 09:50:37 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA24879; Wed, 8 Nov 2000 10:48:57 +0100 (BST) Message-ID: <3A09218A.C42366FE@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: shh@microappliances.com Cc: Jonathan Rosenberg , "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: Re: [SIP] Identification problem References: <20001107175956.69633.qmail@microappliances.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, 08 Nov 2000 09:48:58 +0000 Content-Transfer-Encoding: 7bit shh@microappliances.com wrote: > > Quoting Jonathan Rosenberg : > > > The advantage here is that one could insert URL parameters into the > > record-route, and get them back in the request URI. Not the prettiest way > > to > > go. We could, as an alternative, simply mandate the State header in the > bis > > draft, which would provide a cleaner solution. > > > So, the State header will be a comma separated list (or multiple > state headers) of state ids > one per Route Header. However as one Route header is removed before sending > out the request, the corresponding State header is retained, only to > be removed by the subsequent proxy if it proceses the next route > header. In other words there should be n+1 State headers for > n Route headers in the request. This correlation process can > become tricky. Knowing whether the topmost State info is relevant > to the proxy can be difficult. It doesn't have to be done that way. The State header could very easily include a value by which the proxy can identify itself. In fact the DCS work has already proposed something like this: State = "State" ":" 1#(host ";" state-token *(";" state-token)) state-token = token ["=" (*token | quoted-string)] See: http://search.ietf.org/internet-drafts/draft-ietf-sip-state-00.txt A State header is much cleaner than a hack which overloads the meaning of SIP URL params in Record-Route. That type of approach looks to have greater potential for future deficiencies. 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 Nov 8 04:52: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 EAA22824 for ; Wed, 8 Nov 2000 04:52:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31E974433B; Wed, 8 Nov 2000 03:21:07 -0500 (EST) 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 B53A444337 for ; Wed, 8 Nov 2000 03:20:56 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Nov 2000 09:20:51 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA15693; Wed, 8 Nov 2000 10:19:20 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "M. Ranganathan" , sip@lists.bell-labs.com Subject: Re: [SIP] Error reporting using via header in UDP X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <3A0831ED.827C32D4@nist.gov> In-Reply-To: <3A0831ED.827C32D4@nist.gov> MIME-Version: 1.0 Message-Id: <00110809252500.13411@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 8 Nov 2000 09:20:15 +0000 Content-Transfer-Encoding: 8bit On Tue, 07 Nov 2000, M. Ranganathan wrote: > Hello! > > (Im going to sound like a lawyer again. Yech! :-)). > > Here is the passage from the RFC that I am trying to interpret. In > section 1.4.3: > > If the client sent the request via unicast UDP, the response is sent > to the address contained in the next Via header field (Section 6.46) > of the response. > > I use the term client to refer to the originator of a message. My > questions / assumptions are below: > > 1. The address in the first via header need not necessarily be the peer > address that the server reads from the udp socket when it gets the > message. Of course, it is in the client's best interest to use a > meaningful address. If a server receives a message and the originating host address does not match the value in the top most via header, it adds a received parameter which identifies the IP address of the client. This received parameter is used when routing messages back up stream. Is that what you're asking about? > 2. If the server reads a request that is badly formatted except for the > via header, it can silently drop the message if it wants. In general, > the server is just being nice by returning error messages for udp > requests and is not obliged to do so. Is that a question or a statement? I would expect an error response to be sent if the message can be decoded enough to generate a valid response. > 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 0932 > > _______________________________________________ > 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 Wed Nov 8 06: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 SMTP id GAA23641 for ; Wed, 8 Nov 2000 06:04:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 364934433B; Wed, 8 Nov 2000 05:04:07 -0500 (EST) 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 661B644337 for ; Wed, 8 Nov 2000 05:03:42 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Nov 2000 11:03:36 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA22295; Wed, 8 Nov 2000 12:02:04 +0100 (BST) Message-ID: <3A0932AC.D74ED499@ubiquity.net> From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] failure of proxy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 08 Nov 2000 11:02:04 +0000 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > For things to work consistently, the SRV lookup process should be based on > the pseudo-random number generator I suggested in a previous thread; thats > the one based on a hash of the Call-ID, amongst other things. This gives us > consistent operation for SRV records in general. As I replied in a previous thread (with a bad example) this hash based method gives us nothing in general it only works if you locally cache DNS for the life time of a transaction, for each transaction (hence truly stateless proxy servers do not work ;^) ). The reason for this is simple for the hash method to work the result from the DNS query MUST be identical even in ordering of the RRs each time. As an example of why this may not happen I'll admit my short comings, the first time I implemented SRV lookups I was lazy I found the lowest priority RRs and picked the first one. If I was writing a DNS server I may expect other people to do this, and in a more thorough moment may decide to shuffle the results my server returned for SRV records (this wouldn't provide the same level of load balancing but could help). Also it's possible the zone file might have changed. If you are going to suggest this hashing proposal I'd also think about sorting the results of SRV lookups, although zone file changes will still break it. 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 Nov 8 06:27: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 GAA05283 for ; Wed, 8 Nov 2000 06:27:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 028404433B; Wed, 8 Nov 2000 05:27:07 -0500 (EST) 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 ADF0444337 for ; Wed, 8 Nov 2000 05:26:28 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Nov 2000 11:26:23 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA00169; Wed, 8 Nov 2000 12:24:48 +0100 (BST) From: "Jo Hornsby" To: "Sean Olson" , "Jonathan Rosenberg" Cc: "'Neil Deason'" , "'Bertil Engelholm'" , Subject: RE: [SIP] Identification problem Message-ID: <001b01c04976$80fa26a0$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: <3A07C09B.DAC8B5E5@ericsson.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, 8 Nov 2000 11:24:48 -0000 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > Jonathan Rosenberg wrote: > > > > > > >I like this approach except I would take it a step further and > > >do this for all URLs including SIP URLs. This allows maddr to go > > >back to its original intention for SIP URLs. Plus I hate special > > >cases; this seems (nominally) easier to implement. > > > > Conceptually that is clearly the better way. However, there is > > a backwards compatibility problem. Older rfc2543 implementations > > will use the maddr to forward (if they are working correctly, > > that is), but not an address parameter of the Route header. > > This seems to be a backwards compatibility we can afford to break. > Will an older rfc2543 implementation really work with one based on bis > anyways? There seem to have been some substantial changes in the > mechanisms. At the very least, there is a syntactic change. (I had to > play this card because I believe implementations should handle this > change -- the addition of RR parameters) Hmmm... this backwards compatibility thing is a pain, but how about this: 2543 (Section 6.29) currently states: The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. It contains a globally reachable Request-URI that identifies the proxy server. Each proxy server adds its Request-URI to the beginning of the list. [Note that the text says the proxy adds its Request-URI; it doesn't say any more than that, so it doesn't seem unreasonable to assume there is freedom for perhaps more exotic URI than one might normally find.] The server copies the Record-Route header field unchanged into the response. (Record-Route is only relevant for 2xx responses.) [I would highlight the "unchanged" in this sentence.] 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. If the response contained a Contact header field, the calling user agent adds its content as the last Route header. Unless this would cause a loop, any client MUST send any subsequent requests for this call leg to the first Request-URI in the Route request header field and remove that entry. [And here we have the client sending to the Request-URI in popped Route. Again, it doesn't seem unreasonable to assume that the Request-URI is copied verbatim; the only slight change might be removal of any of (maddr, transport, ttl) parameters, since these were not allowed in the Request-URI in 2543 (Section 2, just before "Headers:".] If the motivation behind retaining backwards compatibility is purely a "we're going to be breaking the spirit of the RFCs/IETF", then this may be a solution... Instead of proxies copying the Request-URI, and mangling the port and maddr, why not just get them to put _their_ SIP URL in, and make the Request-URI a parameter of the SIP URL (suitably escaped, of course). So for instance, say I am an example.com proxy, listening on port 6000. I get the following: INVITE sip:alice@bobs-place.com SIP/2.0 ... I then forward this as (Alice gets about a bit): INVITE sip:alice@charlies-place.com SIP/2.0 ... Record-Route: ... Now if a 2543 client sends a subsequent request in the caller -> callee direction, this proxy should see: INVITE sip:example.com:6000;uri=sip:alice@bobs-place.com SIP/2.0 ... which should be enough information. &:) Now I know we have questioned whether the UA or proxy or whatever will copy the entire Request-URI, but the spec certainly doesn't say that only the user@host:port is copied, so I don't see this as a valid argument. If, OTOH, we are looking at backwards-compatibility from a "work with existing SIP Implementations" standpoint, then I have to say that so much of Record-Route wouldn't have worked anyway (the spec says nothing about building Route:s in the callee -> caller direction), is it really worth worrying? With this approach, we can write into bis, say, that the called UA, when forming requests, renames all "uri" parameters to "original-uri"; and appends a new "uri" parameter with the value of the Contact:/From:. We now have the resilience that Jonathan was addressing (thread: "failure of proxy), since each proxy along the Route can see the final destination. And also, if the request spiralled, we know where on the Route we are (since we have retained the original Request-URIs, too). Now I know that this is a significant change, but as far as I can tell, realistically, no proxy will as yet have been able to Record-Route properly and/or remain call stateful, because we are still finding bugs. Thus it doesn't seem as if there can be real objections to making such a changes, since hopefully they are changes towards having a fully-working mechanism (okay, I guess we think it works now, but it can't be more than 3 months since we spotted that Record-Route: can break in the reverse direction when a request has spiralled; how mature can implementations possibly be?) 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 Nov 8 06: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 GAA11446 for ; Wed, 8 Nov 2000 06:39:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C30544349; Wed, 8 Nov 2000 05:39:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 7C63044337 for ; Wed, 8 Nov 2000 05:38:22 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA8BcTC11911; Wed, 8 Nov 2000 17:08:35 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256991.0040388D ; Wed, 8 Nov 2000 17:11:27 +0530 X-Lotus-FromDomain: HSSBLR From: airoy@hss.hns.com To: "Robert Sparks" Cc: sip@lists.bell-labs.com, archow@hss.hns.com Message-ID: <65256991.004037E6.00@sampark.hss.hns.com> Subject: RE: referred-by syntax (was RE: [SIP] (no subject)) 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, 8 Nov 2000 17:11:25 +0530 Hi, Thanks for posting the proposed new grammar. I have a couple of doubts with the new grammar. According to the grammar you have posted below I can have any number of referenced-urls and ref-signatures in any combination. Further according to this grammar, we could have a ref-signature without a referenced url. Is this allowed?.. The draft-sip-cc-transfer-01 clearly states that the refsignature "contains a signature over the concatenation of referrer-url and referenced url". This implies that the referenced url is mandatory ( as you have rightly pointed out in your mail). The new grammar does not reflect this. Again with the new grammar i could leave out the referenced-url and the refsignature alltogether. This is clearly not allowed. IMHO the new grammar should be, Referred-By = ("Referred-By" | "b") ":" referrer-url ";" referenced-url [";" ref-signature ] referrer-url = ( name-addr | addr-spec ) referenced-url = "ref" "=" "<" URL ">" ref-signature = signature-scheme *( ";" sig-scheme-params ) signature-scheme = "scheme" "=" token sig-scheme-parms = token "=" ( token | quoted-string ) The difference here is removing the " | " and the " * " operators between the referenced url and the ref-signature. I have another doubt. In the draft it states that the Referred-By header can be in any Request message. Why is this so?....It also states that the refernced-url must contain the url in the refer-to header. Does this imply that for a referred-by header to exist a refer-to header should also be present, or does it mean in a REFER request you have both refer-to and referred-by headers and when the Transferee does an INVITE to the target he includes a referred-by header without a refer-to header ?... What is the motivation for limiting the Refer-To header to just SIP-URL and not nameaddr ? .... In your next version of the draft could you inlcude some sample messages with the REFER method in the call-flow diagrams?..thanks regards, Ashok Ashok I Roy @ Hughes Software Systems It's going to be a few more days before I can get the next revision of the REFER draft out. Until then, here's what list discussion has guided the Referred-By syntax into. The motivations for change were 1) Allow URLs containing semicolons to be parsed correctly. This introduced changing the referrer-url from SIPURL to name-addr | addr-spec. Allowing the referrenced URL to be separated is a little more difficult since it is not necessarily a SIP URL. This syntax attempts to resolve the problem by wrapping the URL with <> and requiring any <>s appearing in the URL to be escaped. 2) Allow the parameters to be completely unordered. This requires more text to augment the ABNF. ------------------- Referred-By = ("Referred-By" | "b") ":" referrer-url *( ";" referenced-url | ";" ref-signature ) referrer-url = ( name-addr | addr-spec ) referenced-url = "ref" "=" "<" URL ">" ref-signature = signature-scheme *( ";" sig-scheme-params ) signature-scheme = "scheme" "=" token sig-scheme-parms = token "=" ( token | quoted-string ) A Referred-By header MUST contain exactly one referenced-url. A Referred-By header MUST contain either zero or one ref-signature. Any occurences of "<" or ">" within the URL value in referenced-url must be escaped. ------------ RjS _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 8 06:43:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13163 for ; Wed, 8 Nov 2000 06:43:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F34044349; Wed, 8 Nov 2000 05:43:06 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 6ADAE44337 for ; Wed, 8 Nov 2000 05:42:07 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Nov 8 06:40:41 EST 2000 Received: by lists.bell-labs.com (Postfix) id C933B44380; Wed, 8 Nov 2000 06:27:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 28DE24437D for ; Wed, 8 Nov 2000 06:27:30 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4Y6PRKFJ>; Wed, 8 Nov 2000 11:27:29 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00BD027@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'SIP discussion list'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Hide header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 8 Nov 2000 11:27:28 -0000 I noted in Henning's list of headers for IANA that the Hide header is deprecated. In the bis-02 draft, there appears to be no text that indicates this, or gives any details on what the term means as regards sending and receiving, apart from some discussion in annex I. Is there some proposed text somewhere that states SHOULD NOT for sending, and changes the "m" status in table 6 for proxies. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 07:51:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08374 for ; Wed, 8 Nov 2000 07:51:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 269E74433B; Wed, 8 Nov 2000 06:51:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id BABDC44337 for ; Wed, 8 Nov 2000 06:50:34 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id GAA09047; Wed, 8 Nov 2000 06:50:25 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id GAA29137; Wed, 8 Nov 2000 06:50:25 -0600 (CST) Received: from ericsson.com (kipe51.eraj.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id GAA15462; Wed, 8 Nov 2000 06:50:23 -0600 (CST) Message-ID: <3A094C0D.B9D38807@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: Jo Hornsby Cc: Jonathan Rosenberg , "'Neil Deason'" , "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: Re: [SIP] Identification problem References: <001b01c04976$80fa26a0$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: Wed, 08 Nov 2000 13:50:21 +0100 Content-Transfer-Encoding: 7bit Some ramblings on the subject. /sean Jo Hornsby wrote: Hmmm... this backwards compatibility thing is a pain, but how about this: > If the motivation behind retaining backwards compatibility is > purely a "we're going to be breaking the spirit of the RFCs/IETF", > then this may be a solution... > > Instead of proxies copying the Request-URI, and mangling the > port and maddr, why not just get them to put _their_ SIP URL in, > and make the Request-URI a parameter of the SIP URL (suitably > escaped, of course). > Now I know we have questioned whether the UA or proxy or whatever > will copy the entire Request-URI, but the spec certainly doesn't > say that only the user@host:port is copied, so I don't see this as > a valid argument. But this should be clarified. The UA/proxy MUST copy the entire URI from the Route: header into the Request-URI without modification or omission. > If, OTOH, we are looking at backwards-compatibility from a "work > with existing SIP Implementations" standpoint, then I have to say > that so much of Record-Route wouldn't have worked anyway (the > spec says nothing about building Route:s in the callee -> caller > direction), is it really worth worrying? > I agree completely with this sentiment. > > With this approach, we can write into bis, say, that the called > UA, when forming requests, renames all "uri" parameters to > "original-uri"; and appends a new "uri" parameter with the value > of the Contact:/From:. I'm not sure I see a need for three URIs in this case. You have in the Route: header: 1) The URI of the Proxy (the main URI) 2) The original Request-URI of the request that set up the Route: (the "original-uri" parameter) 3) The URI of the Contact:/From: of the request that set up the Route: (the new "uri" parameter) Do we need the full expressive power of a URI (#1) to know how to route to the proxy? Do we need both 2 & 3? (Did I misunderstand your proposal?) > We now have the resilience that Jonathan was addressing (thread: > "failure of proxy), since each proxy along the Route can see > the final destination. But how does this help? Which is more important: ensuring that a message follows the static route of Route: -or- ensuring that the message gets to the final destination? > And also, if the request spiralled, > we know where on the Route we are (since we have retained the > original Request-URIs, too). > This is an interesting idea. > > Now I know that this is a significant change, but as far as I can > tell, realistically, no proxy will as yet have been able to > Record-Route properly and/or remain call stateful, because we > are still finding bugs. Thus it doesn't seem as if there can be > real objections to making such a changes, since hopefully they > are changes towards having a fully-working mechanism (okay, I > guess we think it works now, but it can't be more than 3 months > since we spotted that Record-Route: can break in the reverse > direction when a request has spiralled; how mature can > implementations possibly be?) > Precis. > 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 Nov 8 08:12: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 IAA15964 for ; Wed, 8 Nov 2000 08:12:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1541244349; Wed, 8 Nov 2000 07:12:08 -0500 (EST) 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 2F12144337 for ; Wed, 8 Nov 2000 07:10:59 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Nov 2000 13:10:53 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA04498; Wed, 8 Nov 2000 14:09:19 +0100 (BST) From: "Jo Hornsby" To: "Sean Olson" Cc: "Jonathan Rosenberg" , "'Neil Deason'" , "'Bertil Engelholm'" , Subject: RE: [SIP] Identification problem Message-ID: <001e01c04985$1ade7b00$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: <3A094C0D.B9D38807@ericsson.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, 8 Nov 2000 13:09:19 -0000 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > Some ramblings on the subject. > /sean > > Jo Hornsby wrote: > > Hmmm... this backwards compatibility thing is a pain, but how > about this: > > > > If the motivation behind retaining backwards compatibility is > > purely a "we're going to be breaking the spirit of the RFCs/IETF", > > then this may be a solution... > > > > Instead of proxies copying the Request-URI, and mangling the > > port and maddr, why not just get them to put _their_ SIP URL in, > > and make the Request-URI a parameter of the SIP URL (suitably > > escaped, of course). > > > > > Now I know we have questioned whether the UA or proxy or whatever > > will copy the entire Request-URI, but the spec certainly doesn't > > say that only the user@host:port is copied, so I don't see this as > > a valid argument. > > But this should be clarified. The UA/proxy MUST copy the entire URI > from the Route: header into the Request-URI without modification or > omission. Oh very much so -- this should be clarified in the bis -- but we'll have to deal with the fact that it's not nailed down in the spec. > > If, OTOH, we are looking at backwards-compatibility from a "work > > with existing SIP Implementations" standpoint, then I have to say > > that so much of Record-Route wouldn't have worked anyway (the > > spec says nothing about building Route:s in the callee -> caller > > direction), is it really worth worrying? > > > > I agree completely with this sentiment. > > > > > With this approach, we can write into bis, say, that the called > > UA, when forming requests, renames all "uri" parameters to > > "original-uri"; and appends a new "uri" parameter with the value > > of the Contact:/From:. > > I'm not sure I see a need for three URIs in this case. You > have in the Route: header: > > 1) The URI of the Proxy (the main URI) > 2) The original Request-URI of the request that set up the Route: (the > "original-uri" parameter) > 3) The URI of the Contact:/From: of the request that set up the > Route: (the > new "uri" parameter) > > Do we need the full expressive power of a URI (#1) to know how to > route to the proxy? > Do we need both 2 & 3? (Did I misunderstand your proposal?) I think you may have misunderstood a subtle point that I'm trying to achieve. I think with this approach, we get the behaviour that a heterogeneous (in the sense RFC 2543 and state-of-the-art bis) network of SIP entities would work as well as a network of purely 2543 SIP entities; that is, Record-Route would work for requests in the caller -> callee direction. Additionally, we might even be lucky enough to get Record-Route working in the callee -> caller direction, although this would require that the caller was using a state-of-the-art UA. (This does assume that the entire URI is copied by 2543 entities, of course.) The reason that I'm going to these lengths, I guess, is to maintain just enough backwards compatibility. > > We now have the resilience that Jonathan was addressing (thread: > > "failure of proxy), since each proxy along the Route can see > > the final destination. > > But how does this help? Which is more important: ensuring that > a message follows the static route of Route: -or- ensuring that > the message gets to the final destination? Probably depends on who I am. If I'm the caller, I'd probably be quite happy if the message got to its final destination and "happened" to miss out all of my networks billing servers. &:) But I understand what you're getting at (I think). For all intents and purposes, it's only the Route that matters; it just gives me a warm fuzzy feeling to know that I'm also being backed up by the Request-URI. > > And also, if the request spiralled, > > we know where on the Route we are (since we have retained the > > original Request-URIs, too). > > > > This is an interesting idea. > > > > > Now I know that this is a significant change, but as far as I can > > tell, realistically, no proxy will as yet have been able to > > Record-Route properly and/or remain call stateful, because we > > are still finding bugs. Thus it doesn't seem as if there can be > > real objections to making such a changes, since hopefully they > > are changes towards having a fully-working mechanism (okay, I > > guess we think it works now, but it can't be more than 3 months > > since we spotted that Record-Route: can break in the reverse > > direction when a request has spiralled; how mature can > > implementations possibly be?) > > > > Precis. 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 Wed Nov 8 09:59: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 JAA27904 for ; Wed, 8 Nov 2000 09:59:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F93644343; Wed, 8 Nov 2000 08:59:06 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 68F4644337 for ; Wed, 8 Nov 2000 08:58:07 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Nov 8 09:57:06 EST 2000 Received: by lists.bell-labs.com (Postfix) id 4048244380; Wed, 8 Nov 2000 09:43:57 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 00B3B4437D for ; Wed, 8 Nov 2000 09:43:56 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA17672; Wed, 8 Nov 2000 08:43:53 -0600 Cc: "'SIP discussion list'" Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA17649; Wed, 8 Nov 2000 08:43:51 -0600 Message-ID: <3A0966A3.30F2A43C@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Internet Software and eServices Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Original-CC: "'SIP discussion list'" Subject: Re: [SIP] Hide header References: <475FF955A05DD411980D00508B6D5FB00BD027@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 08 Nov 2000 08:43:47 -0600 Content-Transfer-Encoding: 7bit "Drage, Keith (Keith)" wrote: > > I noted in Henning's list of headers for IANA that the Hide header is > deprecated. > > In the bis-02 draft, there appears to be no text that indicates this, > or gives any details on what the term means as regards sending and > receiving, apart from some discussion in annex I. Is there some > proposed text somewhere that states SHOULD NOT for sending, and > changes the "m" status in table 6 for proxies. Keith: Digging into some of the (pertinent) emails I have saved, I found this from Henning that may help: > 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@dy > namicsoft.com> <39AE1096.95161017@uab.ericsson.se> <39AE38A0.526A55F8@ubiquity.n > et> <39AF4ADB.B8751B55@dynamicsoft.com> <39AF51F7.CDBFE713@ericsson.fi> <39AF563 > A.8EEB995@dynamicsoft.com> <39AF7E14.FE7886BB@ubiquity.net> <39B06683.FE987438@d > ynamicsoft.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-Length: 2102 > Status: RO > X-Status: $$$$ > X-UID: 0000000040 > > > > 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 > hat 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 > - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software & eServices Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 10:02: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 KAA29196 for ; Wed, 8 Nov 2000 10:02:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CAC34434E; Wed, 8 Nov 2000 09:00:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 50DA64434E for ; Wed, 8 Nov 2000 08:59:21 -0500 (EST) Received: from CINQUECENTO ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id KAA19401; Wed, 8 Nov 2000 10:01:27 -0500 (EST) From: "Robert Sparks" To: Cc: , Subject: RE: referred-by syntax (was RE: [SIP] (no subject)) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <65256991.004037E6.00@sampark.hss.hns.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, 8 Nov 2000 08:57:48 -0600 Content-Transfer-Encoding: 7bit > Hi, > Thanks for posting the proposed new grammar. I have a couple of > doubts with > the new grammar. According to the grammar you have posted below > I can have any number of referenced-urls and ref-signatures in any > combination. Further according to this grammar, we could have a > ref-signature without a > referenced url. Is this allowed?.. Thats why there was normative text attached below the grammar. I agree that the ABNF will allow what you describe. As far as I know, we don't have a good way to express the requirements that the text imposes in the grammar itself. Please reread the text below the grammar and let me know if it answers your above questions sufficiently (I think it does). > The draft-sip-cc-transfer-01 clearly > states that the refsignature "contains a signature over the concatenation > of referrer-url and referenced url". This implies that the referenced url > is mandatory ( as you have rightly pointed out in your mail). The new > grammar does not reflect this. Again with the new grammar i could > leave out > the referenced-url and the refsignature alltogether. This is clearly not > allowed. IMHO the new grammar should be, > > Referred-By = ("Referred-By" | "b") ":" referrer-url ";" > referenced-url [";" ref-signature ] > > referrer-url = ( name-addr | addr-spec ) > > referenced-url = "ref" "=" "<" URL ">" > > ref-signature = signature-scheme *( ";" sig-scheme-params ) > signature-scheme = "scheme" "=" token > sig-scheme-parms = token "=" ( token | quoted-string ) > > The difference here is removing the " | " and the " * " operators between > the referenced url and the ref-signature. In an earlier thread, Jonathan brought up that this (which is similar to the last version of the grammar) forced "ref=" to occur before any of the signature parameters - a restriction that doesn't exist for the other "sip-guidelines" headers (there are order dependencies in things like www-authenticate, but we are trying not to replicate that characteristic). > > > I have another doubt. In the draft it states that the Referred-By header > can be in any Request message. Why is this so?....It also states that the > refernced-url must contain the url in the refer-to header. Does this imply > that for a referred-by header to exist a refer-to header should also be > present, or does it mean in a REFER request you have both refer-to and > referred-by headers and when the Transferee does an INVITE to the > target he > includes a referred-by header without a refer-to header ?... > The last scenario you described is correct. That answers why a Referred-By header can appear in any request - if I send a REFER containing a Referred-By header to a sip URL with method FOO, the resulting FOO would have that Referred-By header. > What is the motivation for limiting the Refer-To header to just > SIP-URL and > not nameaddr ? .... Umm... It doesn't. It says URL, not SIP-URL. You can, for example, REFER to an http URL. (Remember that if you get a reference for a scheme you don't understand or are not willing to process, you just return a 503 as per section 3.5. > > In your next version of the draft could you inlcude some sample messages > with the REFER method in the call-flow diagrams?..thanks That's the plan (and its why the draft didn't come out last week) > > regards, > Ashok > > > Ashok I Roy @ Hughes Software Systems > > > > > It's going to be a few more days before I can get the next > revision of the REFER draft out. Until then, here's what > list discussion has guided the Referred-By syntax into. > > The motivations for change were > > 1) Allow URLs containing semicolons to be parsed correctly. This > introduced changing the referrer-url from SIPURL to name-addr | > addr-spec. Allowing the referrenced URL to be separated is a > little more difficult since it is not necessarily a SIP URL. > This syntax attempts to resolve the problem by wrapping the URL > with <> and requiring any <>s appearing in the URL to be escaped. > > 2) Allow the parameters to be completely unordered. This requires > more text to augment the ABNF. > > ------------------- > Referred-By = ("Referred-By" | "b") ":" referrer-url > *( ";" referenced-url | ";" > ref-signature ) > referrer-url = ( name-addr | addr-spec ) > referenced-url = "ref" "=" "<" URL ">" > ref-signature = signature-scheme *( ";" sig-scheme-params ) > signature-scheme = "scheme" "=" token > sig-scheme-parms = token "=" ( token | quoted-string ) > > A Referred-By header MUST contain exactly one referenced-url. > A Referred-By header MUST contain either zero or one ref-signature. > Any occurences of "<" or ">" within the URL value in referenced-url > must be escaped. > > ------------ > > RjS > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 8 10:11: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 KAA02009 for ; Wed, 8 Nov 2000 10:11:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A9C044358; Wed, 8 Nov 2000 09:11:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 9E21844357 for ; Wed, 8 Nov 2000 09:10:41 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id KAA12887; Wed, 8 Nov 2000 10:05:47 -0500 (EST) Message-ID: <3A096CE9.D85A376C@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: Gethin Liddell Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Error reporting using via header in UDP References: <3A0831ED.827C32D4@nist.gov> <00110809252500.13411@gethin> Content-Type: multipart/alternative; boundary="------------FCB466987B4BE51B576CF90A" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 08 Nov 2000 10:10:33 -0500 --------------FCB466987B4BE51B576CF90A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Gethin Liddell wrote: > > > 2. If the server reads a request that is badly formatted except for the > > via header, it can silently drop the message if it wants. In general, > > the server is just being nice by returning error messages for udp > > requests and is not obliged to do so. > > Is that a question or a statement? I would expect an error response to > be sent if the message can be decoded enough to generate a valid > response. Is this a requirement or a recommendation? (i.e. are silent failures disallowed by the spec. ) Thanks for the clarification on the other question. Regards, Ranga. > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------FCB466987B4BE51B576CF90A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Gethin Liddell wrote:
 
> 2. If the server reads a request that is badly formatted except for the
> via header, it can silently drop the message if it wants. In general,
> the server is just being nice by returning error messages for udp
> requests and is not obliged to do so.

Is that a question or a statement?  I would expect an error response to
be sent if the message can be decoded enough to generate a valid
response.

Is this a requirement  or a recommendation?  (i.e. are silent failures disallowed by the spec. )

Thanks for the clarification on the other question.

Regards,
Ranga.
 

 
-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------FCB466987B4BE51B576CF90A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 10:41: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 KAA10370 for ; Wed, 8 Nov 2000 10:41:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AFF1C4434A; Wed, 8 Nov 2000 09:41:06 -0500 (EST) 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 E963044337 for ; Wed, 8 Nov 2000 09:40:43 -0500 (EST) Received: by esebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 8 Nov 2000 17:40:36 +0200 Message-ID: From: Markus.Isomaki@nokia.com To: sip@lists.bell-labs.com Cc: schulzrinne@cs.columbia.edu MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP registration draft - routing via home network Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 8 Nov 2000 17:40:33 +0200 I have a question regarding draft-schulzrinne-sip-register-00. In the draft it says: -- 5 Home Services while in Visited Network For some applications, the user would like to employ services of the home network while generating outbound requests in the visited network. The visiting UA needs to detect that it is in a foreign network and insert a Route header pointing to its home proxy server. -- I guess this would be another use for Route header within the initial INVITE and would be "loose" source-routing as has been discussed in some other threads. However, how does the UA learn about it's home proxy server? Static configuration works well if there is a single proxy address always to be used. But in some cases the home network may assign "serving" proxies dynamically for registering users - even based on user's service control needs. In this case 200 OK for REGISTER would need to carry information about the proxy, right? Should this be done by using Record-Route in REGISTER & 200 or by some other means? Regards, Markus > -----Original Message----- > From: EXT Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: 06 October, 2000 18:03 > To: sip@lists.bell-labs.com > Subject: [SIP] New draft on SIP registration > > > I've written a quick draft on some of the issues related to how to do > SIP registration when "visiting" networks. I would appreciate > feedback. > The draft does not propose new SIP extensions, except for a possible > Digest parameter to increase registration security. > > The draft is > http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-regi > ster-00.txt > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 11:29:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21867 for ; Wed, 8 Nov 2000 11:29:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92AA84433E; Wed, 8 Nov 2000 10:29:06 -0500 (EST) 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 348B244337 for ; Wed, 8 Nov 2000 10:28:56 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Nov 2000 16:28:50 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA17008; Wed, 8 Nov 2000 17:27:20 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: mranga@nist.gov, "M. Ranganathan" Subject: Re: [SIP] Error reporting using via header in UDP X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com References: <3A0831ED.827C32D4@nist.gov> <00110809252500.13411@gethin> <3A096CE9.D85A376C@nist.gov> In-Reply-To: <3A096CE9.D85A376C@nist.gov> MIME-Version: 1.0 Message-Id: <00110816332201.14495@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 8 Nov 2000 16:30:22 +0000 Content-Transfer-Encoding: 8bit > 2. If the server reads a request that is badly formatted except for > the via header, it can silently drop the message if it wants. In > general, the server is just being nice by returning error messages > for udp requests and is not obliged to do so. > Is that a question or a statement? I would expect an error response > to be sent if the message can be decoded enough to generate a valid > response. > Is this a requirement or a recommendation? (i.e. are silent > failures disallowed by the spec. ) well the spec only says SHOULD when talking about the 400 response so no its not mandatory -- 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 Nov 8 13: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 NAA18772 for ; Wed, 8 Nov 2000 13:10:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 782AE4433B; Wed, 8 Nov 2000 12:10:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id 192C644337 for ; Wed, 8 Nov 2000 12:09:24 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3FQGCS>; Wed, 8 Nov 2000 10:06:50 -0800 Received: from rwcjfmule01 (p216.usslc5.stsn.com [12.23.124.216]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4V3FQGCQ; Wed, 8 Nov 2000 10:06:44 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: James_Renkel@3com.com, Jean-Francois Mule Cc: sip@lists.bell-labs.com Message-ID: <001001c049ae$e4c8dcc0$3601a8c0@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <88256991.00605E8C.00@hqoutbound.ops.3com.com> Subject: [SIP] RE: SIP and t.38 internet-draft comments Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 8 Nov 2000 10:08:26 -0800 Content-Transfer-Encoding: 7bit Thank you Jim. If there are no more comments, I will then post a quick update of the ID reflecting the groups' comments: - addition of Record-route in call flow sample (see Cseq discussion with Arju) - minor editorial comments received Jean-Francois. Clarent Corp. > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: Wednesday, November 08, 2000 9:33 AM > To: Jean-Francois Mule > Cc: sip@lists.bell-labs.com > Subject: RE: Request for information on using T.30/T.37/T.38 with > SIP/SDP /RTP > > > > > Jean-Francois, > > I and the other folk here at 3Com Carrier Networks that reviewed your > draft > (http://search.ietf.org/internet-drafts/draft-mule-sip-t38call > flows-00.t > xt) > have found it very interesting and potentially useful, but we > don't have > any > other more specific comments to make at this time. Perhaps as we get > further > into implementation we'll have questions or comments for you. > > Jim Renkel > Director, Advanced Technology & System Engineering > 3Com Carrier Networks Business > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 14:57:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16560 for ; Wed, 8 Nov 2000 14:57:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 109FE4433E; Wed, 8 Nov 2000 13:57:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (uzura.cisco.com [161.44.3.77]) by lists.bell-labs.com (Postfix) with ESMTP id 3188D44337 for ; Wed, 8 Nov 2000 13:56:47 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [161.44.53.27]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA15929; Wed, 8 Nov 2000 14:56:04 -0500 (EST) Message-ID: <3A09AFEC.BA377173@cisco.com> From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Some brief comments on the SIP MIB 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, 08 Nov 2000 14:56:28 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgschul@attglobal.net] > > Sent: Sunday, October 29, 2000 8:30 AM > > To: Kevin Lingle > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Some brief comments on the SIP MIB > > > > > > > > > > - ULS should probably at least mention LDAP as an example. > > > > > > ULS has undergone some changes. We had a request to handle > > prioritzed > > > backup addressess. I also got some comments that having one generic > > > ULS address wasn't sufficient. Systems may have multiple > > resources they > > > use to determine where users are. > > > > > > You can view the proposal on sip-mib@egroups.com archive > > > [http://www.egroups.com/message/sip-mib/40]. There has been no > > > feedback on the proposal yet (unfortunately that is typical). > > > I would appreciate if you could take a quick look. Btw, the > > > current proposal does not actualy handle prioritized addresses > > > correctly (i need to consider that further). What is your view > > > on having the ability to specify backup addresses ULS? > > > > Probably needs discussion by those building proxies, as I can > > primarily > > speak from our own experience. In our server, locations are > > derived from > > several different sources > > > > - LDAP > > - an SQL database for registrations > > - a set of user-configurable scripts that provide mappings > > from SIP user > > ids to other user id's, e.g., resolution of email aliases. > > > > While being able to change the LDAP URL via the management console is > > useful, I doubt that describing or changing the others is particularly > > helpful (and not likely to be feasible, given that just > > connecting to a > > different SQL server just doesn't magically make the table definitions > > appear there). > > I think the notion of generalzied, configurable ULS through SNMP is > fundamentally a hopeless cause. THe problem is that a location service is an > abstract concept. It can be the result of program execution, LDAP queries, > SQL queries, ENUM, finger, whois, local files, IVR interaction, etc. Your > assumption is that in all cases there is at least an IP address that > indicates where the service is. I don't think thats generally true. Certain > location services (local file, IVR interaction, program execution), don't > really have such a concept. this is the general feeling i've been having about this. it's good to hear you say this. that said, i'd still like to explore the issue a bit more. > > So, there are two choices. Either completely drop this ULS thing, or > restrict it to a specific set of known location services which do have a > common set of configuration information. Access to an external database is > probably pretty broad but has a common set of information that you could > configure (IP address, username and password for access, port, transport, > database instance name) i can't drop ULS completely w/out replacing it with something. primarily because to this point, the ULS addr object has been used for a gateway to specify the ip address of the sip proxy/redirect it uses. question: is calling a sip server an abuse or mis-use of the term "user location server"?? i was thinking that from a gateway's perspective, it looks to a sip server as one potential user location server (ie, doesn't know where to go next to setup session to a terminating gateway) now i'm wondering if that's confusing sip things with non-sip things like external databases. i've been using the term that way for a long time and noone has really objected. so i will at least need sip server address info somewhere to replace ULS addr object if it goes away. perhaps a specific sipServerAddr object added to SIP-UA-MIB?? we were trying to also allow for backup sip server addresses... a request we got a while back from someone on the sip-mib list. do you think that is of value?? i'd like to try and identify a small set of known location services that we think will be common enough that you'd expect to find them used by most sip entities. if such a list can be identified then the question is how appropriate is that content for a standard sip mib? if used by most sip entities, it would be convenience to provide the ability to address these resources. the alternative would be non-standard variety of ways to configure such things (other mibs). i could use some wisdom/guidance here, jonathan. kevin -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 Nov 8 15:03:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18025 for ; Wed, 8 Nov 2000 15:03:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2ADE744349; Wed, 8 Nov 2000 14:03:07 -0500 (EST) 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 895384433E for ; Wed, 8 Nov 2000 14:02:39 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G3Q006012BKV9@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 8 Nov 2000 20:02:08 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G3Q004J12BKPV@firewall.mcit.com>; Wed, 08 Nov 2000 20:02:08 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0G3Q00H01278PF@dgismtp03.wcomnet.com>; Wed, 08 Nov 2000 19:59:43 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G3Q00H01277P0@dgismtp03.wcomnet.com>; Wed, 08 Nov 2000 19:59:31 +0000 (GMT) Received: from wcom.com ([166.46.18.211]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G3Q00FMX25VSV@dgismtp03.wcomnet.com>; Wed, 08 Nov 2000 19:59:16 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] UAC Record Routing in draft-ietf-sip-call-flows-01.txt To: Jonathan Rosenberg Cc: "'Neil Deason'" , Sip List Message-id: <3A09B1EC.8283E23C@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 08 Nov 2000 14:05:01 -0600 Content-Transfer-Encoding: 7bit I will fix this. I thought RFC2543bis read that the maddr was required, but I see upon re-reading that this is only true for proxies. Alan. Jonathan Rosenberg wrote: > > -----Original Message----- > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > Sent: Friday, November 03, 2000 8:34 AM > > To: Sip List > > Subject: [SIP] UAC Record Routing in draft-ietf-sip-call-flows-01.txt > > > > > > The way the UAC builds the Route on a final 200 response > > in 3.1.2 of the call flows draft doesn't look quite > > right ... > > > > 3.1.2 Successful SIP to SIP through two proxies > > > > User A Proxy 1 Proxy 2 User B > > | | | | > > | INVITE F1 | | | > > |--------------->| | | > > | 407 F2 | | | > > |<---------------| | | > > | ACK F3 | | | > > |--------------->| | | > > | INVITE F4 | | | > > |--------------->| INVITE F5 | | > > | (100) F6 |--------------->| INVITE F7 | > > |<---------------| (100) F8 |--------------->| > > | |<---------------| | > > | | | 180 F9 | > > | | 180 F10 |<---------------| > > | 180 F11 |<---------------| | > > |<---------------| | 200 F12 | > > | | 200 F13 |<---------------| > > | 200 F14 |<---------------| | > > |<---------------| | | > > | ACK F15 | | | > > |--------------->| ACK F16 | | > > | |--------------->| ACK F17 | > > | | |--------------->| > > > > F14 200 OK Proxy 1 -> A > > > > SIP/2.0 200 OK > > Via: SIP/2.0/UDP here.com:5060 > > Record-Route: , > > > > From: BigGuy > > To: LittleGuy ;tag=314159 > > Call-ID: 12345601@here.com > > CSeq: 1 INVITE > > Contact: LittleGuy > > Content-Type: application/sdp > > Content-Length: 134 > > > > v=0 > > o=UserB 2890844527 2890844527 IN IP4 there.com > > s=Session SDP > > c=IN IP4 110.111.112.113 > > t=0 0 > > m=audio 3456 RTP/AVP 0 > > a=rtpmap:0 PCMU/8000 > > > > > > F15 ACK A -> Proxy 1 > > > > ACK sip:UserB@there.com SIP/2.0 > > Via: SIP/2.0/UDP here.com:5060 > > Route: , > > > > From: BigGuy > > To: LittleGuy ;tag=314159 > > Call-ID: 12345601@here.com > > CSeq: 1 ACK > > Content-Length: 0 > > > > The UAC should build the Route header in the ACK by > > copying the 200 response Record-Route header, > > reversing the order and then adding the Contact as > > the last entry. (Note the 1st entry in the Route is > > subsequently removed when the client actually sends F15). > > But in this case the last entry has become an IP address. > > Shouldn't the UAC just copy the Contact and not try > > and do any resolution of it? > > Correct. This behavior is really bad, actually. It depends on being able to > perform a resolution of the Contact address outside of the realm where it is > supposed to be resolved. If there is a private DNS running, or some kind of > local information is placed in the hostname, this resolution will fail at > the called party. > > Alan - can you please fix? > > 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 15: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 PAA18957 for ; Wed, 8 Nov 2000 15:07:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C64ED44356; Wed, 8 Nov 2000 14:05:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C3BC544356 for ; Wed, 8 Nov 2000 14:04:47 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA16526; Wed, 8 Nov 2000 15:04:34 -0500 (EST) Message-ID: <3A09B1D2.47FA11FD@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Lingle Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Some brief comments on the SIP MIB References: <3A09AFEC.BA377173@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, 08 Nov 2000 15:04:34 -0500 Content-Transfer-Encoding: 7bit Kevin Lingle wrote: > > > i can't drop ULS completely w/out replacing it with something. primarily > because to this point, the ULS addr object has been used for a gateway to > specify the ip address of the sip proxy/redirect it uses. That is not in any way related to a "location server". If you want to specify the default outbound proxy (which this seems to be), that would be useful, but it's a separate category from a location server. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 15:22:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22246 for ; Wed, 8 Nov 2000 15:22:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 46A1E4433B; Wed, 8 Nov 2000 14:22:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.in.huawei.com (unknown [203.197.168.165]) by lists.bell-labs.com (Postfix) with ESMTP id 711F74438D for ; Tue, 7 Nov 2000 02:10:51 -0500 (EST) Received: from 203.197.168.165 (203.197.182.39 [203.197.182.39]) by mail.in.huawei.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WLBZ08H5; Tue, 7 Nov 2000 13:42:22 +0530 Reply-To: From: Prasanna X-mailserver: Sent using the PostMaster (v3.1.5) To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01C048A7.90CB6140" 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] REGISTER with non-SIP URL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 7 Nov 2000 10:43:29 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0088_01C048A7.90CB6140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, Can somebody please suggest what may be response for a REGISTER request with a non-SIP URL, say a TEL URL? Should it be a 400 response or a 405 response? Thanks 'N Regards, Prasanna Huawei Technologies India ------=_NextPart_000_0088_01C048A7.90CB6140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
    Can somebody please = suggest what may=20 be response for a REGISTER request with a non-SIP URL, say a TEL=20 URL?
    Should it be a 400 = response or a 405=20 response?
 
Thanks 'N Regards,
Prasanna
 
Huawei Technologies
India
------=_NextPart_000_0088_01C048A7.90CB6140-- -------------------------------------------------------------- HUAWEI (BANGALORE) BUSINESS OPERATION, 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 Wed Nov 8 15:25:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22906 for ; Wed, 8 Nov 2000 15:25:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1FC764435B; Wed, 8 Nov 2000 14:22:18 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 778CD44337 for ; Tue, 7 Nov 2000 05:05:23 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06617; Tue, 7 Nov 2000 06:05:15 -0500 (EST) Message-Id: <200011071105.GAA06617@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-state-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 07 Nov 2000 06:05:14 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Extensions for supporting Distributed Call State Author(s) : B. Marshall et al. Filename : draft-ietf-sip-state-00.txt Pages : 12 Date : 06-Nov-00 This document describes an extension to the Session Initiation Protocol (SIP) that enables proxies to distribute call state to user agents. The state information can be returned to the proxy when the user agent requests a change in the characteristics of the active call. By providing the ability to distribute state to the user agents where it can be securely stored, proxy servers can remain stateless for the duration of the call. This mechanism allows a proxy server to provide services that depend on call state, while still being stateless. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-state-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-state-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-state-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001106151121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-state-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-state-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001106151121.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 15: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 SMTP id PAA24539 for ; Wed, 8 Nov 2000 15:32:26 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 29D5044360; Wed, 8 Nov 2000 14:22:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 8F07944337 for ; Tue, 7 Nov 2000 05:05:26 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06561; Tue, 7 Nov 2000 06:05:10 -0500 (EST) Message-Id: <200011071105.GAA06561@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-call-auth-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 07 Nov 2000 06:05:09 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Extensions for Media Authorization Author(s) : B. Marshall et al. Filename : draft-ietf-sip-call-auth-00.txt Pages : 15 Date : 06-Nov-00 This document describes the need for call authorization and offers a mechanism for call authorization that can be used for admission control and against denial of service attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-call-auth-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-call-auth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-call-auth-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001106151109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-call-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-call-auth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001106151109.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 15:39: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 PAA26128 for ; Wed, 8 Nov 2000 15:39:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F83C44366; Wed, 8 Nov 2000 14:22:40 -0500 (EST) 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 2FD8044337 for ; Wed, 8 Nov 2000 05:59:37 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Nov 2000 11:59:31 UT Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA13295; Wed, 8 Nov 2000 12:58:03 +0100 (BST) Message-ID: <005f01c0497a$f680d550$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] Use of Record-Route and Contact Headers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 8 Nov 2000 11:56:43 -0000 Content-Transfer-Encoding: 7bit Hi, This will be the third time that I have posted this message, without receiving a satisfactory reply. Please gimme some feedback! Thanks Phil ---------------------------------------------------------------------------- -- Hi, Table 4 of bis02 states that a Contact header can occur in the following response types: 1xx 2xx 3xx 485 (Ambiguous) However, Table 5 states that Record-Route can occur in the following response types: 2xx 401 (Unauthorized) 484 (Address Incomplete) I don't see how a response can include a Record-Route, if it can't contain a Contact. I believe that 401 and 484 should be added to the list of response types for a Contact header. What do you think? Cheers Phil _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 15:43: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 PAA27227 for ; Wed, 8 Nov 2000 15:43:45 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 391814436B; Wed, 8 Nov 2000 14:22:50 -0500 (EST) 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 162B544337 for ; Wed, 8 Nov 2000 11:30:54 -0500 (EST) 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 eA8HU9D22843; Wed, 8 Nov 2000 09:30:09 -0800 (PST) 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 eA8HUlr05643; Wed, 8 Nov 2000 09:30:47 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256991.006060CB ; Wed, 8 Nov 2000 09:32:42 -0800 X-Lotus-FromDomain: 3COM From: James_Renkel@3com.com To: Jean-Francois Mule Cc: sip@lists.bell-labs.com Message-ID: <88256991.00605E8C.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] RE: Request for information on using T.30/T.37/T.38 with SIP/SDP /RTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 8 Nov 2000 11:33:19 -0600 Jean-Francois, I and the other folk here at 3Com Carrier Networks that reviewed your draft (http://search.ietf.org/internet-drafts/draft-mule-sip-t38callflows-00.txt) have found it very interesting and potentially useful, but we don't have any other more specific comments to make at this time. Perhaps as we get further into implementation we'll have questions or comments for you. Jim Renkel Director, Advanced Technology & System Engineering 3Com Carrier Networks Business _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 15:51:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29546 for ; Wed, 8 Nov 2000 15:51:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7403B44356; Wed, 8 Nov 2000 14:30:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (uzura.cisco.com [161.44.3.77]) by lists.bell-labs.com (Postfix) with ESMTP id 91FC34433B for ; Wed, 8 Nov 2000 14:29:26 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [161.44.53.27]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA18628; Wed, 8 Nov 2000 15:28:11 -0500 (EST) Message-ID: <3A09B773.22C1E62B@cisco.com> From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , sip@lists.bell-labs.com, sip-mib@egroups.com Subject: Re: [SIP] Some brief comments on the SIP MIB References: <3A09AFEC.BA377173@cisco.com> <3A09B1D2.47FA11FD@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 08 Nov 2000 15:28:35 -0500 Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: > > Kevin Lingle wrote: > > > > > > > i can't drop ULS completely w/out replacing it with something. primarily > > because to this point, the ULS addr object has been used for a gateway to > > specify the ip address of the sip proxy/redirect it uses. > > That is not in any way related to a "location server". If you want to > specify the default outbound proxy (which this seems to be), that would > be useful, but it's a separate category from a location server. that was what i was afraid of :( the mib needs to be corrected then. funny, this uls addr object has been in the mib since -00 rev of the I-D and the description has been very clear that a sip server was a possible use of the object. i am going to create a new object in the SIP-UA-MIB that is specifically for configuring the address of the sip server a user agent use. again, is there any value in allowing for multiple server addresses to be configured (eg, for backup purposes)? we had a request for that a while back on sip-mib alias. kevin > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 Nov 8 16: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 QAA04070 for ; Wed, 8 Nov 2000 16:10:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A55944433B; Wed, 8 Nov 2000 15:10:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 28AA744337 for ; Wed, 8 Nov 2000 15:09:46 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id EA6001E006 for ; Wed, 8 Nov 2000 16:09:39 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA11645 for ; Wed, 8 Nov 2000 16:09:39 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id QAA99720 for sip@lists.bell-labs.com; Wed, 8 Nov 2000 16:09:27 -0500 (EST) Message-Id: <200011082109.QAA99720@fish-ha.research.att.com> Subject: [SIP] REGISTER with non-SIP URL To: sip@lists.bell-labs.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, 8 Nov 2000 16:09:27 -0500 (EST) Prasanna wrote: > Hi All, > Can somebody please suggest what may be response for a REGISTER request > with a non-SIP URL, say a TEL URL? > Should it be a 400 response or a 405 response? How about 200? There are two URLs in the register request - the address-of-record whose registration is to created or updated (the To: header), and the place future non-REGISTER requests should be directed (the Contact: header). A tel: URL in the To: header is asking for a registration to be created or updated with that address, which admittedly may end up with less than global scope. A tel: URL in the Contact: header is asking for future requests to be directed to a PSTN gateway. A tel: URL in both may be nearly useless, but there seems little reason to reject it. The sender obviously thought there was some point in having such an entry at the registrar. Bill Marshall wtm@research.att.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 16:18: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 QAA05853 for ; Wed, 8 Nov 2000 16:18:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5A634433B; Wed, 8 Nov 2000 15:18:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (uzura.cisco.com [161.44.3.77]) by lists.bell-labs.com (Postfix) with ESMTP id 8627844337 for ; Wed, 8 Nov 2000 15:17:06 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [161.44.53.27]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA22779; Wed, 8 Nov 2000 16:15:53 -0500 (EST) Message-ID: <3A09C2A1.4E12A680@cisco.com> From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , sip@lists.bell-labs.com, sip-mib@egroups.com Subject: Re: [SIP] Some brief comments on the SIP MIB References: <3A09AFEC.BA377173@cisco.com> <3A09B1D2.47FA11FD@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 08 Nov 2000 16:16:17 -0500 Content-Transfer-Encoding: 7bit how about this configuring sip server address in a user agent? this table would be defined in the SIP-UA-MIB module and allow the old sipUserLocationServerAddress object in the SIP-COMMON-MIB to no longer be used (incorrectly) for this purpose... and actually be removed. note: a table and the use of applIndex are inherent in the way all of the sip mib modules are defined (see http://search.ietf.org/internet-drafts/draft-ietf-sip-mib-01.txt) -- -- SIP Server Configuration -- sipUACfgSipServerTable OBJECT-TYPE SYNTAX SEQUENCE OF SipUACfgSipServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains SIP server configuration objects applicable to each SIP user agent in this system. The instances of SIP entities are uniquely identified by applIndex." ::= { sipUACfgSipServer 1 } sipUACfgSipServerEntry OBJECT-TYPE SYNTAX SipUACfgSipServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of server configuration." INDEX { applIndex, sipUACfgSipServerIndex } ::= { sipUACfgSipServerTable 1 } SipUACfgSipServerEntry ::= SEQUENCE { sipUACfgSipServerAddrIndex Unsigned32, sipUACfgSipServerAddrType InetAddressType, sipUACfgSipServerAddr InetAddress, sipUACfgSipServerStatus RowStatus } sipUACfgSipServerAddrIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier of a server address when multiple addresses are configured by the SIP entity. If one address isn't reachable, then another can be tried." ::= { sipUACfgSipServerEntry 1 } sipUACfgSipServerAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the type of address contained in the associated instance of sipUACfgSipServerAddr." DEFVAL { ipv4 } REFERENCE "INET-ADDRESS-MIB (RFC 2851)" ::= { sipUACfgSipServerEntry 2 } sipUACfgSipServerAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the address of a SIP server this user agent will use to proxy/redirect calls." ::= { sipUACfgSipServerEntry 3 } sipUACfgSipServerAddrStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to control rows in this table. 'active' : the row's information is completely populated and that information is being used by the user agent. 'notInService' : the row's address is not being used by the user agent, but will remain in the table. 'notReady' : key information is missing thus, preventing the row from being made 'active' (eg, no address specified). 'createAndGo' : only allowed if the manager also provides a varbind for sipUACfgSipServerAddr object in the same set operation. 'createAndWait' : not applicable. 'destroy' : the row's address will no longer be used by the user agent and the row will be removed from the table." ::= { sipUACfgSipServerEntry 4 } "Henning G. Schulzrinne" wrote: > > Kevin Lingle wrote: > > > > > > > i can't drop ULS completely w/out replacing it with something. primarily > > because to this point, the ULS addr object has been used for a gateway to > > specify the ip address of the sip proxy/redirect it uses. > > That is not in any way related to a "location server". If you want to > specify the default outbound proxy (which this seems to be), that would > be useful, but it's a separate category from a location server. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 Nov 8 16:24: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 QAA07128 for ; Wed, 8 Nov 2000 16:24:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0479A4436B; Wed, 8 Nov 2000 15:18:17 -0500 (EST) 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 1550144337 for ; Wed, 8 Nov 2000 15:17:50 -0500 (EST) 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 eA8LH4D18567; Wed, 8 Nov 2000 13:17:04 -0800 (PST) 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 eA8LHfr15613; Wed, 8 Nov 2000 13:17:41 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256991.007522F9 ; Wed, 8 Nov 2000 13:19:26 -0800 X-Lotus-FromDomain: 3COM From: James_Renkel@3com.com To: Kevin Lingle Cc: "Henning G. Schulzrinne" , Jonathan Rosenberg , sip@lists.bell-labs.com, sip-mib@egroups.com Message-ID: <88256991.00751E43.00@hqoutbound.ops.3com.com> Subject: Re: [SIP] Some brief comments on the SIP MIB 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, 8 Nov 2000 15:19:57 -0600 Kevin, I think there is a definite need for configuring multiple server addresses in a SIP UAC. For example, our PSTN gateways can be configured for up to 8 SIP proxies. Using REGISTERs, they determine which ones are alive, and then distribute calls among the alive SIP proxies via one of a number of user selectable algorithms. I think this would be a very good addition to the SIP UA MIB. Jim Kevin Lingle on 11/08/2000 02:28:35 PM Sent by: Kevin Lingle To: "Henning G. Schulzrinne" cc: Jonathan Rosenberg , sip@lists.bell-labs.com, sip-mib@egroups.com (James Renkel/MW/US/3Com) Subject: Re: [SIP] Some brief comments on the SIP MIB "Henning G. Schulzrinne" wrote: > > Kevin Lingle wrote: > > > > > > > i can't drop ULS completely w/out replacing it with something. primarily > > because to this point, the ULS addr object has been used for a gateway to > > specify the ip address of the sip proxy/redirect it uses. > > That is not in any way related to a "location server". If you want to > specify the default outbound proxy (which this seems to be), that would > be useful, but it's a separate category from a location server. that was what i was afraid of :( the mib needs to be corrected then. funny, this uls addr object has been in the mib since -00 rev of the I-D and the description has been very clear that a sip server was a possible use of the object. i am going to create a new object in the SIP-UA-MIB that is specifically for configuring the address of the sip server a user agent use. again, is there any value in allowing for multiple server addresses to be configured (eg, for backup purposes)? we had a request for that a while back on sip-mib alias. kevin > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 16:57: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 QAA14327 for ; Wed, 8 Nov 2000 16:57:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6BDB34433B; Wed, 8 Nov 2000 15:57:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id D0B4944337 for ; Wed, 8 Nov 2000 15:56:08 -0500 (EST) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id VAA05695 for ; Wed, 8 Nov 2000 21:55:52 GMT From: Jin-Gen.Wang@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 VAA16649 for ; Wed, 8 Nov 2000 21:55:51 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Nov 2000 14:57:46 -0700 Message-ID: <350829A9DA9FD411841200508BF9F0600C6097@n0217idc1.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] performance numbers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 8 Nov 2000 14:58:04 -0700 Hello, does anybody have stress test performance numbers of a SIP proxy, UAC, and UAS? I am interested in a sustained call rate as well as a burst call rate. Thanks. Jin-Gen Wang 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 Nov 8 17: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 RAA15075 for ; Wed, 8 Nov 2000 17:00:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7A9644433B; Wed, 8 Nov 2000 16:00:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 652EF44337 for ; Wed, 8 Nov 2000 15:59:19 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA24324; Wed, 8 Nov 2000 16:59:08 -0500 (EST) Message-ID: <3A09CCAE.C20277EB@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP registration draft - routing via home network 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, 08 Nov 2000 16:59:10 -0500 Content-Transfer-Encoding: 7bit I would like to avoid configuration as much as possible, as every configuration option increases complexity. Thus, 'home' is unambiguously defined by the user's From address. The server at that address can then forward the request as needed. I would be curious why this is not sufficient, as it is the same principle used for incoming calls. We may be submitting a draft on general UA configuration soon; it might be appropriate to include this there. Also, with the discussion about Route headers, something like Route: sip:callee@callee-domain.com ;at=home.com would avoid problems on URL content (or maddr). Markus.Isomaki@nokia.com wrote: > > I have a question regarding draft-schulzrinne-sip-register-00. In the draft > it says: > -- > 5 Home Services while in Visited Network > For some applications, the user would like to employ services of the > home network while generating outbound requests in the visited > network. The visiting UA needs to detect that it is in a foreign > network and insert a Route header pointing to its home proxy server. > -- > I guess this would be another use for Route header within the initial INVITE > and would be "loose" source-routing as has been discussed in some other > threads. However, how does the UA learn about it's home proxy server? Static > configuration works well if there is a single proxy address always to be > used. But in some cases the home network may assign "serving" proxies > dynamically for registering users - even based on user's service control > needs. In this case 200 OK for REGISTER would need to carry information > about the proxy, right? Should this be done by using Record-Route in > REGISTER & 200 or by some other means? > > Regards, > Markus -- 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 Nov 8 19:16: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 TAA15038 for ; Wed, 8 Nov 2000 19:16:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B5044433B; Wed, 8 Nov 2000 18:16:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 1354644337 for ; Wed, 8 Nov 2000 18:15:14 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id SAA04188; Wed, 8 Nov 2000 18:15:03 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id SAA04852; Wed, 8 Nov 2000 18:15:02 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA18001; Wed, 8 Nov 2000 18:15:02 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id SAA15146; Wed, 8 Nov 2000 18:15:10 -0600 (CST) Message-Id: <200011090015.SAA15146@b04a24.exu.ericsson.se> Subject: Re: [SIP] Possible REFER problem? To: etremblay@mediatrix.com (Eric Tremblay) Cc: jdrosen@dynamicsoft.com ('Jonathan Rosenberg'), Cliff.Harris@nokia.com ('Cliff.Harris@nokia.com'), etremblay@mediatrix.com (Eric Tremblay), sip@lists.bell-labs.com ('sip@lists.bell-labs.com') In-Reply-To: from "Eric Tremblay" at Oct 25, 2000 09:04:30 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 8 Nov 2000 18:15:10 -0600 (CST) Content-Transfer-Encoding: 7bit Eric Tremblay writes: >I'm reviving and old thread ;) > >If you remember, the problem was when doing call transfer with consultation >with the REFER request, how can we make sure that the INVITE request (from >the Transferee to the Transfer Target) is going to reach the exact same >User-Agent as the one that was consulted by the Transferor. > >The solution was to use the header "Accept-Contact" and specify the contact >of the transfer target. At the risk of sounding daft, I don't see why using the "Contact:" header as the new "INVITE" URI is considered Evil in this case. When explaining the difference between, say, the "From:" (or "To:") field and the "Contact:" field, I generally think of "From:"/"To:" as being the persistent URI for contacting the appropriate resource in an abstract sense (by resource, I mean "Adam Roach" or "helpdesk staffer" or "sales representative"), while the "Contact:" URI indicates "where to get to me (as a particular instance of that resource) on this particular device at this particular moment." Obviously, the most useful application of this latter piece of information is routing of subsequent messages for a particular call -- but I don't see why it absolutely MUST be the only use for this information. For the "Contact" information to be useful in any way, it needs to be something that can be routed when used as a Request-URI; it wouldn't work for "BYE" messages otherwise, right? So, if the transferee were passed this information to be used as the Request-URI, there should be no discernable problems with the INVITE (or other appropriate method) arriving at the partcular instance of the desired resource on a particular device. Since no one else has raised this point, I'm going to assume that I'm too blind to see the elephant in the room. So, could someone explain *why* using a Contact URI in this manner would be inappropriate behavior? -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 8 19:33: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 TAA18676 for ; Wed, 8 Nov 2000 19:33:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 408364434E; Wed, 8 Nov 2000 18:33:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id 543E244343 for ; Wed, 8 Nov 2000 18:32:41 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3FQ2ZD>; Wed, 8 Nov 2000 16:30:08 -0800 Received: from rwcjfmule01 (p76.usslc10.stsn.com [63.161.205.76]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4V3FQ2ZB; Wed, 8 Nov 2000 16:29:57 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: drwalker@ss8networks.com, joon_maeng@vtel.com, klingle@cisco.com Cc: sip@lists.bell-labs.com, sip-mib@egroups.com Subject: [SIP] Some comments on the SIP MIB - operState/AdminState (draft-ietf-sip-mib-01.txt) Message-ID: <001e01c049e4$6ca90040$2101a8c0@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <88256991.00751E43.00@hqoutbound.ops.3com.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, 8 Nov 2000 16:31:37 -0800 Content-Transfer-Encoding: 7bit The comments here address mainly the application state variables: 2 variables in the current sip mib: sipServiceOperStatus and sipServiceAdminStatus. --- Usage status: When the SIP entity is up, it would be nice to have a simple variable showing its usage. This way, as a sysadmin, I could query the app and if it is up and idle, or up and busy. Could we add a usage variable? Something like: sipServiceUsageStatus OBJECT-TYPE SYNTAX INTEGER idle(0), active(1), busy(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the current usage state of the SIP application. idle(0) : The application is currently not in use. active(1) : The application is in use, and has sufficient spare operating capacity. busy(2) : The application is in use but it has no spare operating capacity." ::= { sipCommonCfgEntry x } --- Regarding the number of state variables The operational status variable contains numerous state information which overlap. For example, when the status is 'testing', the sysadmin does not know from the MIB whether the service is up or down. On large scale systems, we may want to allow test procedures on some SIP functionality of the device while calls are being served. Unless we have a way to describe this properly, we expose ourselves to implementation & operational issues. The operability of the SIP service should be binary: enabled or disabled. We could have another variable to reflect the procedural aspects (testing, initializing, ...) or standby options. Same applies to the AdminState: I'd prefer keep a convention already established where the admin state is either locked (sip application administratively down), shutting down or unlocked. Comments? Without getting into too much detailed vars, I believe we could clarify the admin/oper/usage states along with some procedural vars so that both vendors and operators have a clear way of setting/querying the SIP apps behavior. Cheers, Jean-Francois Mule 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 Wed Nov 8 19:47: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 TAA21700 for ; Wed, 8 Nov 2000 19:47:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 938F54433E; Wed, 8 Nov 2000 18:47:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id C466B4433B for ; Wed, 8 Nov 2000 18:46:05 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3FQ27J>; Wed, 8 Nov 2000 16:43:32 -0800 Received: from rwcjfmule01 (p76.usslc10.stsn.com [63.161.205.76]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4V3FQ272; Wed, 8 Nov 2000 16:43:30 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: drwalker@ss8networks.com, joon_maeng@vtel.com, klingle@cisco.com Cc: sip@lists.bell-labs.com, sip-mib@egroups.com Subject: [SIP] Some comments on the SIP MIB - configuration of security options (draft-ietf-sip-mib-01.txt) Message-ID: <002301c049e6$50d6e420$2101a8c0@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <001e01c049e4$6ca90040$2101a8c0@rwcjfmule01> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 8 Nov 2000 16:45:10 -0800 Content-Transfer-Encoding: 7bit The current MIB allows to specify the authentication method that is used by servers to authenticate request originators (sipProxyAuthMethod). The granularity is this config param means: a proxy will challenge all requests or none. There might be cases where a proxy requires authentication on some but not all requests (typically, authenticate REGISTER only then you are trusted and can speak freely ;-), or authenticate REGISTER, INVITE, BYE -- for the ACK, it is okay, etc.). Shall we allow this level of granularity for the configuration of sip proxies? Jean-Francois Mule 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 Wed Nov 8 19:58: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 TAA24059 for ; Wed, 8 Nov 2000 19:58:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B68644433B; Wed, 8 Nov 2000 18:58:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 3850644337 for ; Wed, 8 Nov 2000 18:57:02 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA05596; Wed, 8 Nov 2000 19:56:47 -0500 (EST) Message-ID: <3A09F650.571E88EE@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: drwalker@ss8networks.com, joon_maeng@vtel.com, klingle@cisco.com, sip@lists.bell-labs.com, sip-mib@egroups.com Subject: Re: [SIP] Some comments on the SIP MIB - configuration of security options (draft-ietf-sip-mib-01.txt) References: <002301c049e6$50d6e420$2101a8c0@rwcjfmule01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 08 Nov 2000 19:56:48 -0500 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > > The current MIB allows to specify the authentication method that is used by > servers to authenticate request originators (sipProxyAuthMethod). The > granularity is this config param means: a proxy will challenge all requests > or none. > > There might be cases where a proxy requires authentication on some but not > all requests (typically, authenticate REGISTER only then you are trusted > and can speak freely ;-), or authenticate REGISTER, INVITE, BYE -- for the > ACK, it is okay, etc.). > > Shall we allow this level of granularity for the configuration of sip > proxies? Unfortunately, it's more complicated than that. Our server allows configuration for each local user, so that (for example) help@cs.columbia.edu requests, but does not require authentication for non-REGISTER (but does for REGISTER), while calls to chair@cs.columbia.edu requires authentication for all requests. I really doubt you want to carry all of this in SNMP. > > Jean-Francois Mule > Clarent Corp. > > _______________________________________________ > 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 Nov 8 20:52:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07606 for ; Wed, 8 Nov 2000 20:52:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E19F14433B; Wed, 8 Nov 2000 19:52:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id DBC6144337 for ; Wed, 8 Nov 2000 19:51:24 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Wed, 8 Nov 2000 19:46:55 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 8 Nov 2000 19:51:05 -0600 Message-ID: <9A9367D1556AD21182C40000F80930AB02B165A2@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: "'sip@lists.bell-labs.com'" Cc: "Jonathan Rosenberg (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C049EF.85379E40" X-Orig: Subject: [SIP] Caller Preferences and MESSAGE method Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 8 Nov 2000 19:51:04 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C049EF.85379E40 Content-Type: text/plain; charset="iso-8859-1" Hi, I think there is definite value in adding the MESSAGE method to the draft-ietf-sip-callerprefs-02. I see *all three* headers being of value to the MESSAGE method i.e. Accept-Contact, Reject-Contact and Request-Disposition. Some examples: 1. The sender of the IM could require that his Message be delivered only to a device with a class = "business". This could use the Accept-Contact header. 2. If you want to save your buddy valuable air-time charges you could send an IM with the following header Reject-Contact: sip:mybuddy@downtown.com;mobility="mobile" 3. You could use the Request-Disposition to ensure that the Contact list returned for the Message is tried sequentially. Thanks and Regards, Sriram Parameswar Nortel Networks ------_=_NextPart_001_01C049EF.85379E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Caller Preferences and MESSAGE method

Hi,

I think there is definite value in adding the MESSAGE = method to the draft-ietf-sip-callerprefs-02. I see *all three* headers = being of value to the MESSAGE method i.e. Accept-Contact, = Reject-Contact and Request-Disposition.

Some examples:

1. The sender of the IM could require that his = Message be delivered only to a device with a class =3D = "business".
   This could use the Accept-Contact = header.
2. If you want to save your buddy valuable air-time = charges you could send an IM with the following header
   Reject-Contact: = sip:mybuddy@downtown.com;mobility=3D"mobile"
3. You could use the Request-Disposition to ensure = that the Contact list returned for the Message is tried = sequentially.

Thanks and Regards,

Sriram Parameswar
Nortel Networks

------_=_NextPart_001_01C049EF.85379E40-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 00:02: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 AAA26849 for ; Thu, 9 Nov 2000 00:02:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B5D604433B; Wed, 8 Nov 2000 23:02:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id 805DA44337 for ; Wed, 8 Nov 2000 23:01:33 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <4V3FQJ81>; Wed, 8 Nov 2000 20:58:58 -0800 Received: from rwcjfmule01 (p76.usslc10.stsn.com [63.161.205.76]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4V3FQJ8D; Wed, 8 Nov 2000 20:58:53 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Jonathan Rosenberg'" , archow@hss.hns.com, sip@lists.bell-labs.com Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft) Message-ID: <005201c04a09$fef64f50$2101a8c0@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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, 8 Nov 2000 21:00:34 -0800 Content-Transfer-Encoding: 7bit If No, then No. For my own records, can you quote the part of the current specification(s) stating that proxies MUST NOT modify the Cseq? I've screened rfc2543bis-02 again and I cannot find any statement that would flag the proposed call flow as "not compliant" (the call flow in question illustrated a proxy modifying Cseq on 2 call legs). Any time the usage of Cseq is explained, it is in reference to a particular call leg or SIP transaction. It understand it is one thing to implement a profile of the spec that follows the common sense to encourage interoperability(why would you ever purposely increment Cseq in a proxy?), however, the spec should unambiguously clarify this. And this was the intent of this separate thread. Jean-Francois Mule PS: I'll modify the call flow to reflect the same Cseq on both sides because this is not the intent of the SIP-T.38 ID. So, yes. Jonathan Rosenberg wrote: > > No. > > The call flow is a very standard re-INVITE type of thing. > There is no reason > why this proxy should behave any differently from any other > proxy. Proxies > do not modify CSeq. Period. There is no reason why this > cannot be a standard > flow, and for purposes of interoperability, it should be. The > flow you have > in the document is not compliant to the spec. > > -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 Thu Nov 9 01: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 BAA04669 for ; Thu, 9 Nov 2000 01:41:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EA9914433B; Thu, 9 Nov 2000 00:41:07 -0500 (EST) 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 B0F7E44337 for ; Thu, 9 Nov 2000 00:40:19 -0500 (EST) 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 MAA01737 for ; Thu, 9 Nov 2000 12:19:07 GMT Received: from wipro.com ([164.164.28.228]) by ace.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA3D56 for ; Thu, 9 Nov 2000 12:05:23 +0530 Message-ID: <3A0A498B.B889E4B0@wipro.com> 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 Subject: Re:[SIP] I-D ACTION:draft-ietf-sip-state-00.txt Content-Type: text/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, 09 Nov 2000 12:21:55 +0530 Content-Transfer-Encoding: 7bit Hi , Went through the distributable call state draft. It is a move in the right direction as the proxies should be holding as little state information as possible in order to scale up. But it seems the idea of having a separate state header might not be needed. The nesting of state headers across proxies adds to complexity and overhead. Existing UA implementations cannot support state header. An alternative will be to use the Record-route option already defined. The proxy which adds a record route header(means the proxy is interested in keeping track of the call.)can add the state info duly encrypted as a parameter to record route header. Now only the proxy which inserted the record route header needs to interpret the state parameters. Note that record route is valid per call leg basis. Thus the proxy can selectively choose call legs which it is interested in. .The UA implementations need not worry as they are supposed to insert the Record-route header unchanged into the responses. As record - routing support is mandatory, this seems to be a better solution that needs very little changes. Also alleviates the need to live with one more header!!! This is what I feel from the first look...Or am I missing something? Thanks & regards Anuraj Ennai SIP Designer Wipro Technologies -Bangalore-India Subject: [SIP] I-D ACTION:draft-ietf-sip-state-00.txt Date: Tue, 07 Nov 2000 06:05:14 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: sip@lists.bell-labs.com 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 Extensions for supporting Distributed Call State Author(s) : B. Marshall et al. Filename : draft-ietf-sip-state-00.txt Pages : 12 Date : 06-Nov-00 This document describes an extension to the Session Initiation Protocol (SIP) that enables proxies to distribute call state to user agents. The state information can be returned to the proxy when the user agent requests a change in the characteristics of the active call. By providing the ability to distribute state to the user agents where it can be securely stored, proxy servers can remain stateless for the duration of the call. This mechanism allows a proxy server to provide services that depend on call state, while still being stateless. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-state-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-state-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-state-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 02:43:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12386 for ; Thu, 9 Nov 2000 02:43:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 36B8B4433B; Thu, 9 Nov 2000 01:43:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 6788644337 for ; Thu, 9 Nov 2000 01:42:38 -0500 (EST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id eA97gnC28005; Thu, 9 Nov 2000 13:12:50 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256992.002AA4F4 ; Thu, 9 Nov 2000 13:15:47 +0530 X-Lotus-FromDomain: HSSBLR From: airoy@hss.hns.com To: "Robert Sparks" Cc: sip@lists.bell-labs.com, archow@hss.hns.com Message-ID: <65256992.002AA469.00@sampark.hss.hns.com> Subject: RE: referred-by syntax (was RE: [SIP] (no subject)) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 9 Nov 2000 13:15:44 +0530 Robert , thanks for the clarifications. I understood the text after the grammar, just that i thought that the grammar should be sufficient to reflect that. Is there a problem with describing the grammar like this, Referred-By = ("Referred-By" | "b") ":" referrer-url ";" (referred-by-params) referred-by-params = ";" referenced-url [";" ref-signature ] | ";" ref-signature ";" referenced-url I am not sure if this allowed by ABNF formal specs, but i don't see why it shouldn't be. >>>>>> > What is the motivation for limiting the Refer-To header to just > SIP-URL and > not nameaddr ? .... >>Umm... It doesn't. It says URL, not SIP-URL. You can, for example, REFER >>to an http URL. (Remember that if you get a reference for a scheme you >>don't understand or are not willing to process, you just return a 503 as >>per section 3.5. >>>>>>>> Sorry about that....i wasn't too clear...i was asking you why the display name was not allowed... ex: "ashok I roy " < airoy@hss.hns.com > In the Refer-To header only the URL is allowed. again why isn't that allowed in the referenced-url of the Referred-By header ? In the referenced-url it would be more appropriate to allow it, becuase the new grammar mandates angle braces around the URL. Thanks. regards, -Ashok ------------------------------------- Ashok I 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 Nov 9 04:40: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 EAA01900 for ; Thu, 9 Nov 2000 04:40:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F1004433B; Thu, 9 Nov 2000 03:40:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id DF0A344337 for ; Thu, 9 Nov 2000 03:39:47 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V797L0DL; Thu, 9 Nov 2000 10:37:48 +0100 From: "Hisham Khartabil" 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.50.4133.2400 Subject: [SIP] Contact header is a 200 response to SUBSCRIBE for IMPP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 9 Nov 2000 11:40:57 +0200 Content-Transfer-Encoding: 7bit Section 4.2 of the presence draft has the following examples: SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0 Via: SIP/2.0/UDP userpc.example.com To: sip:jdrosen@dynamicsoft.com From: sip:user@example.com Contact: sip:user@userpc.example.com Call-ID: knsd08alas9dy@3.4.5.6 CSeq: 1 SUBSCRIBE Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP presenceserver.dynamicsoft.com Via: SIP/2.0/UDP userpc.example.com To: sip:jdrosen@dynamicsoft.com From: sip:user@example.com Contact: sip:user@userpc.example.com Record-Route: sip:jdrosen@example.com;maddr=presenceserver.dynamicsoft.com Expires: 3600 Call-ID: knsd08alas9dy@3.4.5.6 CSeq: 1 SUBSCRIBE Content-Type: application/xpidf+xml Content-Length: 287
Then, it goes on to say: "Notice that the response has mirrored many fields from the request,including the To, From, Call-ID, CSeq, and Via headers. The PA has also added a Contact header, providing an address where it can be reached. The response also contains a Record-Route header. This header was presumably inserted by the proxy (the address in the maddr header is that of a presence server acting as a proxy), and is reflected in the 200 OK response. The response also contains a presence document for the presentity, and a Contact header. The Contact headers in a response to SUBSCRIBE list all the current addresses which have been subscribed." The example shows that the Contact header in the response does actually list the current address which has been subscribed (user@userpc.example.com). But I fail to see where the Contact header that the PA added providing an address where it can be reached. Regards, Hisham Khartabil Hotsip Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 04:48: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 EAA05189 for ; Thu, 9 Nov 2000 04:48:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09EF94433B; Thu, 9 Nov 2000 03:48:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 79D9A44337 for ; Thu, 9 Nov 2000 03:47:27 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V797L013; Thu, 9 Nov 2000 10:45:22 +0100 From: "Hisham Khartabil" To: "Phil Hoffer" , Subject: RE: [SIP] Use of Record-Route and Contact Headers 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) In-Reply-To: <005f01c0497a$f680d550$5334c3c1@ubiquity.co.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 9 Nov 2000 11:48:31 +0200 Content-Transfer-Encoding: 7bit I think the way it works is that if a Contact header has been omitted in a response and there is a record-route, you would use the URI in the To: field. Regards, Hisham Hotsip Finland -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Phil Hoffer Sent: Wednesday, 8 November 2000 1:57 PM To: sip@lists.bell-labs.com Subject: [SIP] Use of Record-Route and Contact Headers Hi, This will be the third time that I have posted this message, without receiving a satisfactory reply. Please gimme some feedback! Thanks Phil ---------------------------------------------------------------------------- -- Hi, Table 4 of bis02 states that a Contact header can occur in the following response types: 1xx 2xx 3xx 485 (Ambiguous) However, Table 5 states that Record-Route can occur in the following response types: 2xx 401 (Unauthorized) 484 (Address Incomplete) I don't see how a response can include a Record-Route, if it can't contain a Contact. I believe that 401 and 484 should be added to the list of response types for a Contact header. What do you think? Cheers Phil _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 9 04: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 SMTP id EAA08067 for ; Thu, 9 Nov 2000 04:55:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3AB0F4433B; Thu, 9 Nov 2000 03:55:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B7B2B44337 for ; Thu, 9 Nov 2000 03:54:47 -0500 (EST) Received: from dynamicsoft.com (ip77.honxr1.ras.tele.dk [195.249.119.77]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA24202; Thu, 9 Nov 2000 04:56:57 -0500 (EST) Message-ID: <3A0A746D.7339F480@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: "'Jonathan Rosenberg'" , archow@hss.hns.com, sip@lists.bell-labs.com Subject: Re: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft) References: <005201c04a09$fef64f50$2101a8c0@rwcjfmule01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 09 Nov 2000 10:54:53 +0100 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > > If No, then No. > For my own records, can you quote the part of the current specification(s) > stating that proxies MUST NOT modify the Cseq? It's a definitional thing, so to speak. If the CSeq is changed the request doesn't belong to the same transaction and is simply a different request. A proxy modifies requests in transit but by definition relayed requests are equivalent to the original request in some sense, and certainly must belong to the same transaction. Anders _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 05:12:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15156 for ; Thu, 9 Nov 2000 05:12:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 995524433B; Thu, 9 Nov 2000 04:12:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 58CCF44337 for ; Thu, 9 Nov 2000 04:11:54 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V797L025; Thu, 9 Nov 2000 11:09:59 +0100 From: "Hisham Khartabil" To: "Jean-Francois Mule" , "'Jonathan Rosenberg'" , , Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <005201c04a09$fef64f50$2101a8c0@rwcjfmule01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 9 Nov 2000 12:13:07 +0200 Content-Transfer-Encoding: 7bit Section 12.1.3 of the bis states: "The To, From, Call-ID, and Contact tags are copied exactly from the original request. The proxy SHOULD change the Request-URI to indicate the server where it intends to send the request." So I guess it says nothing about the Cseq. Frankly, I think it should state all the headers that may not be copied and indicate that the rest MUST be copied. Regards, Hisham Khartabil Hotsip Finland -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jean-Francois Mule Sent: Thursday, 9 November 2000 7:01 AM To: 'Jonathan Rosenberg'; archow@hss.hns.com; sip@lists.bell-labs.com Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft) If No, then No. For my own records, can you quote the part of the current specification(s) stating that proxies MUST NOT modify the Cseq? I've screened rfc2543bis-02 again and I cannot find any statement that would flag the proposed call flow as "not compliant" (the call flow in question illustrated a proxy modifying Cseq on 2 call legs). Any time the usage of Cseq is explained, it is in reference to a particular call leg or SIP transaction. It understand it is one thing to implement a profile of the spec that follows the common sense to encourage interoperability(why would you ever purposely increment Cseq in a proxy?), however, the spec should unambiguously clarify this. And this was the intent of this separate thread. Jean-Francois Mule PS: I'll modify the call flow to reflect the same Cseq on both sides because this is not the intent of the SIP-T.38 ID. So, yes. Jonathan Rosenberg wrote: > > No. > > The call flow is a very standard re-INVITE type of thing. > There is no reason > why this proxy should behave any differently from any other > proxy. Proxies > do not modify CSeq. Period. There is no reason why this > cannot be a standard > flow, and for purposes of interoperability, it should be. The > flow you have > in the document is not compliant to the spec. > > -Jonathan R. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 09:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16149 for ; Thu, 9 Nov 2000 09:29:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4582F4433B; Thu, 9 Nov 2000 08:29:07 -0500 (EST) 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 A205244337 for ; Thu, 9 Nov 2000 08:28:20 -0500 (EST) Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id JAA15506; Thu, 9 Nov 2000 09:27:52 -0500 (EST) Message-ID: <3A0AB45F.FD5F2921@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil Cc: Jean-Francois Mule , "'Jonathan Rosenberg'" , archow@hss.hns.com, sip@lists.bell-labs.com Subject: Re: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft) 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, 09 Nov 2000 09:27:43 -0500 Content-Transfer-Encoding: 7bit Suggested wording change that reflects the fact that proxies should copy the whole request, not just the minimal header fields: The proxy server {\MUST} copy all request header fields to the outgoing request. It {\MAY} add other header fields. Hisham Khartabil wrote: > > Section 12.1.3 of the bis states: > > "The To, From, Call-ID, and Contact tags are copied exactly from the > original request. The proxy SHOULD change the Request-URI to indicate the > server where it intends to send the request." > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 09:51:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24447 for ; Thu, 9 Nov 2000 09:51:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1777D44352; Thu, 9 Nov 2000 08:51:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id C94F244337 for ; Thu, 9 Nov 2000 05:21:07 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11125; Thu, 9 Nov 2000 06:20:58 -0500 (EST) Message-Id: <200011091120.GAA11125@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-06.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, 09 Nov 2000 06:20:57 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : 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-06.txt Pages : 7 Date : 08-Nov-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-06.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-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-isup-mime-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001108122215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-isup-mime-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-isup-mime-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001108122215.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 Nov 9 09:53: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 JAA25399 for ; Thu, 9 Nov 2000 09:53:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9AA5444359; Thu, 9 Nov 2000 08:51:29 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from diana.inter.net.il (diana.inter.net.il [192.114.186.19]) by lists.bell-labs.com (Postfix) with ESMTP id 5245F44337 for ; Thu, 9 Nov 2000 07:26:33 -0500 (EST) Received: from pcx ([213.8.197.164]) by diana.inter.net.il (Mirapoint) with SMTP id ADP39690; Thu, 9 Nov 2000 15:26:09 +0200 (IST) Message-ID: <006601c04a58$f8eaf8a0$02646464@domaind> From: "Dov Ben-Asher" To: Cc: References: <8025697B.0056D145.00@marconicomms.com> <39ECF02B.6D4AF522@cs.columbia.edu> Organization: Startek Technologies 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] FREE SIP Testing Toolkit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 9 Nov 2000 16:25:52 +0200 Content-Transfer-Encoding: 7bit Hi, Please note that in order to promote the development of new SIP applications, Startek Technologies provides a FREE SIP Testing Toolkit - The IPNess(tm) SIP Messenger. The SIP Messenger allows you to send, receive and monitor SIP Messages under Windows-98 and Windows-NT. The IPNess(tm) SIP Messenger can be downloaded from www.ipness.com . Thanks, Dov Ben-Asher. Startek Technologies. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 11:18: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 LAA28256 for ; Thu, 9 Nov 2000 11:18:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A422544343; Thu, 9 Nov 2000 10:18:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from convexant.com (unknown [12.105.64.134]) by lists.bell-labs.com (Postfix) with ESMTP id 9077B4433D for ; Thu, 9 Nov 2000 10:17:24 -0500 (EST) Received: from winphoria.com [12.105.64.189] by convexant.com with ESMTP (SMTPD32-6.00) id ABAF94023A; Thu, 09 Nov 2000 12:15:27 -0500 Message-ID: <3A0ADB9E.D51DCBC7@winphoria.com> From: Antonio Sarabia X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1smp 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] Call ID in third party registration. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 09 Nov 2000 11:15:10 -0600 Content-Transfer-Encoding: 7bit Hi, My apologies for the very basic question, but I would really appreciate if someone could drop a few lines to explain the benefit for a UA of maintaining the same call id for all REGISTER within a boot cycle. Also, in the particular scenario where a UA is doing third party registration for a few others, doesn't the call id become useless to match requests and responses? (and the Cseq is the only way to match them). Or should there be in this scenario a different Call ID for each of the entities that are being registered by the third party?? thank you very much, Antonio. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 11:26: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 LAA02005 for ; Thu, 9 Nov 2000 11:26:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 683714435C; Thu, 9 Nov 2000 10:26:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id E7EAA4433D for ; Thu, 9 Nov 2000 10:25:48 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id IAA16048 for ; Thu, 9 Nov 2000 08:21:23 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 From: David Shrader To: SIP List Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [SIP] Contact: header in re-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: Thu, 09 Nov 2000 11:17:01 -0500 Content-Transfer-Encoding: 7bit Table 4 indicates that the Contact: header is mandatory "m" in the INVITE request. Is this necessary for a re-INVITE message when the two endpoints have already established communication. I think this is similar to the Record-Route mechanism in which the route is recorded once and applies to subsequent requests on the same call leg. For that matter, if the Contact were to change. Do we change the Record-Route/Route as well? David ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 11:59: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 LAA13282 for ; Thu, 9 Nov 2000 11:59:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D43AE44343; Thu, 9 Nov 2000 10:59:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 21EA14433D for ; Thu, 9 Nov 2000 10:58:55 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA11032; Thu, 9 Nov 2000 10:58:35 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id KAA08377; Thu, 9 Nov 2000 10:58:34 -0600 (CST) Received: from ericsson.com (arael25m101.ericsson.se [130.100.251.230]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA19115; Thu, 9 Nov 2000 10:58:28 -0600 (CST) Message-ID: <3A0AD7B0.8F020CCA@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: Phil Hoffer Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Use of Record-Route and Contact Headers References: <005f01c0497a$f680d550$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: Thu, 09 Nov 2000 17:58:24 +0100 Content-Transfer-Encoding: 7bit I must ask why you want to include a Contact: in either a 401 or a 484. In particular, I am very interested to know what you would put in a Contact: that was returned in a 484? (I agree in general that you should be able to use a Contact: header anywhere you use a Record-Route:. I'm just curious what applications you have in mind for these cases) Regards Sean Olson Phil Hoffer wrote: > Hi, > > This will be the third time that I have posted this message, without > receiving a satisfactory reply. > Please gimme some feedback! > > Thanks > Phil > > ---------------------------------------------------------------------------- > -- > > Hi, > > Table 4 of bis02 states that a Contact header can occur in the following > response types: > > 1xx > 2xx > 3xx > 485 (Ambiguous) > > However, Table 5 states that Record-Route can occur in the following > response types: > > 2xx > 401 (Unauthorized) > 484 (Address Incomplete) > > I don't see how a response can include a Record-Route, if it can't contain a > Contact. > I believe that 401 and 484 should be added to the list of response types for > a Contact header. > > What do you think? > > Cheers > Phil > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 9 12:44: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 MAA29245 for ; Thu, 9 Nov 2000 12:44:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 723794433D; Thu, 9 Nov 2000 11:44:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (uzura.cisco.com [161.44.3.77]) by lists.bell-labs.com (Postfix) with ESMTP id C40F744337 for ; Thu, 9 Nov 2000 11:43:32 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [161.44.53.27]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA22817; Thu, 9 Nov 2000 12:41:15 -0500 (EST) Message-ID: <3A0AE1D3.500F51B0@cisco.com> From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: Jean-Francois Mule , drwalker@ss8networks.com, joon_maeng@vtel.com, sip@lists.bell-labs.com, sip-mib@egroups.com Subject: Re: [SIP] Some comments on the SIP MIB - configuration of security options (draft-ietf-sip-mib-01.txt) References: <002301c049e6$50d6e420$2101a8c0@rwcjfmule01> <3A09F650.571E88EE@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 09 Nov 2000 12:41:39 -0500 Content-Transfer-Encoding: 7bit this issue does look like it can be relatively complex and open to a variety of solutions with different levels of granularity. for the standard sip mibs we should try and avoid complexity. vendors should be able to decide whether they want to express their more elaborate auth configuration mechanisms via vendor specific mib extensions. we should not do anything in the standard mib that would prevent, impede or conflict with vendors being able to do that. i believe the sipProxyAuthMethod object's purpose to specify the method used and not get into the particulars of when that method is applied. that said, it does look like the value 'none' and it's current description go beyond that intended purpose. the description says 'none' means no authentication will be performed. perhaps that is a point of confusion. maybe 'none' should be changed to 'unknown' and the description altered to not imply anything about authentication being performed? comments? additionally, we recently got a request to alter the syntax of this object so that multiple auth methods could be in play at once. that would be done by making the object's syntax BITS rather than INTEGER. you could turn on bits for any combination of 'basic', 'digest', or 'pgp'. the value of 0 would likely imply 'none'. so while we're on the subject are there any comments regarding this proposed change (ie, to specify multiple auth methods)? i am currently planning on making this change, so if there are strong arguments against i'd like to hear them now rather than later. kevin "Henning G. Schulzrinne" wrote: > > Jean-Francois Mule wrote: > > > > The current MIB allows to specify the authentication method that is used by > > servers to authenticate request originators (sipProxyAuthMethod). The > > granularity is this config param means: a proxy will challenge all requests > > or none. > > > > There might be cases where a proxy requires authentication on some but not > > all requests (typically, authenticate REGISTER only then you are trusted > > and can speak freely ;-), or authenticate REGISTER, INVITE, BYE -- for the > > ACK, it is okay, etc.). > > > > Shall we allow this level of granularity for the configuration of sip > > proxies? > > Unfortunately, it's more complicated than that. Our server allows > configuration for each local user, so that (for example) > help@cs.columbia.edu requests, but does not require authentication for > non-REGISTER (but does for REGISTER), while calls to > chair@cs.columbia.edu requires authentication for all requests. I really > doubt you want to carry all of this in SNMP. > > > > > Jean-Francois Mule > > Clarent Corp. > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 Thu Nov 9 14:03: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 OAA26933 for ; Thu, 9 Nov 2000 14:03:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E53344341; Thu, 9 Nov 2000 13:03:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 62B1B44337 for ; Thu, 9 Nov 2000 11:22:08 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Nov 2000 17:22:02 UT Received: from phoffer by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id SAA02754; Thu, 9 Nov 2000 18:20:10 +0100 (BST) Message-ID: <000c01c04a71$3ec40ed0$5334c3c1@ubiquity.co.uk> From: "Phil Hoffer" To: "Sean Olson" Cc: References: <005f01c0497a$f680d550$5334c3c1@ubiquity.co.uk> <3A0AD7B0.8F020CCA@ericsson.com> Subject: Re: [SIP] Use of Record-Route and Contact Headers MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 9 Nov 2000 17:19:40 -0000 Content-Transfer-Encoding: 7bit > I must ask why you want to include a Contact: in either a > 401 or a 484. In particular, I am very interested to know > what you would put in a Contact: that was returned in a 484? > (I agree in general that you should be able to use a Contact: > header anywhere you use a Record-Route:. I'm just curious > what applications you have in mind for these cases) > > Regards > Sean Olson ; Thu, 9 Nov 2000 14:04:38 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6126B4435C; Thu, 9 Nov 2000 13:03:20 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rautu.eng.telia.fi (rautu.eng.telia.fi [195.10.149.21]) by lists.bell-labs.com (Postfix) with ESMTP id 7B44544369 for ; Thu, 9 Nov 2000 11:45:44 -0500 (EST) Received: (from jh@localhost) by rautu.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id BAA00376; Thu, 9 Nov 2000 01:00:30 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14857.56078.513077.833140@rautu.eng.telia.fi> To: Jonathan Rosenberg Cc: "'Keith Robinson'" , "'Christer Holmberg'" , sip@lists.bell-labs.com, Igor Slepchin , sean.olson@ericsson.com Subject: RE: [SIP] Redirect server returning new From header In-Reply-To: References: 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: Thu, 9 Nov 2000 01:00:30 +0200 (EET) Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > If the calling UA is known only by this number, you are correct. The privacy > specification addresses exactly this requirement. The problem is when I make > a call from my yahoo SIP account (sip:jdrosen@yahoo.com), and the yahoo > proxy needs to insert my phone number into the request. What I am saying is > that since yahoo does not own or adminster the PSTN numbering space, it has > no way to verifiably correlate my yahoo address with my phone number. The > same problem exists in the reverse; my phone company has no easy way to > reliably verify that a valid additional sip address for me is > jdrosen@yahoo.com. i fully agree. in the yahoo case, the sip/ss7 gateway could authenticate the user and use its own pstn number as the calling number. -- juha _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 14:08: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 OAA28344 for ; Thu, 9 Nov 2000 14:08:20 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4ADC644368; Thu, 9 Nov 2000 13:03:32 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by lists.bell-labs.com (Postfix) with ESMTP id 5C10D44366 for ; Thu, 9 Nov 2000 11:54:47 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id eA9HsRc17674; Thu, 9 Nov 2000 19:54:27 +0200 From: Juha Heinanen Message-ID: <14858.58579.579036.850219@lohi.eng.telia.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: sip@lists.bell-labs.com X-Mailer: VM 6.75 under Emacs 19.34.1 Subject: [SIP] bye and record route Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 9 Nov 2000 19:54:27 +0200 (EET) Content-Transfer-Encoding: 7bit section 4.2.4 bye says: If the INVITE request contained a Contact header, the callee SHOULD send a BYE request to that address rather than the From address. if the invite had record route header, shouldn't the bye request be send to its maddr instead? -- juha _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 14:12: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 OAA29215 for ; Thu, 9 Nov 2000 14:12:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A000C4436D; Thu, 9 Nov 2000 13:03:42 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DCDA74433B for ; Thu, 9 Nov 2000 13:00:56 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA27630 for ; Thu, 9 Nov 2000 14:03:11 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YTN3>; Thu, 9 Nov 2000 13:59:25 -0500 Message-ID: From: Dean Willis To: "IETF 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] WG Last Call on draft-ietf-isup-mime-06.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, 9 Nov 2000 13:59:24 -0500 After one last very minor tweak, I believe we are ready to have a working-group last call on the ISUP-MIME draft, closing November 23. The latest rev has been sent to the drafts editor and can also be downloaded from: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt And remember, vote early, vote often. -- Dean Willis SIP WG co-chair. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 14:29: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 OAA04095 for ; Thu, 9 Nov 2000 14:29:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A250044337; Thu, 9 Nov 2000 13:28:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailwall.tti.net (mailwall.ttimail.com [216.86.19.5]) by lists.bell-labs.com (Postfix) with ESMTP id C453C44336 for ; Thu, 9 Nov 2000 13:27:23 -0500 (EST) Received: from mailhost.ttiworld.com (unverified) by mailwall.tti.net (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Thu, 9 Nov 2000 13:27:17 -0600 Received: by mailhost.ttiworld.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 13:27:31 -0600 Message-ID: <69DEAC407D3B6A48AA71F5D09966F7DB41CCBB@mailhost.ttiworld.com> From: Kevin Summers To: "IETF SIP (E-mail)" Subject: RE: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 9 Nov 2000 13:27:26 -0600 Which RFC defines Content-Disposition and its parameters? -----Original Message----- From: Dean Willis [mailto:dwillis@dynamicsoft.com] Sent: Thursday, November 09, 2000 12:59 PM To: IETF SIP (E-mail) Subject: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt After one last very minor tweak, I believe we are ready to have a working-group last call on the ISUP-MIME draft, closing November 23. The latest rev has been sent to the drafts editor and can also be downloaded from: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt And remember, vote early, vote often. -- Dean Willis SIP WG co-chair. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.inip.com ********************************************************************** _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 14:35: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 OAA05295 for ; Thu, 9 Nov 2000 14:35:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 67E6E44372; Thu, 9 Nov 2000 13:29:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 4480944355 for ; Thu, 9 Nov 2000 13:28:12 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id LAA04411 for ; Thu, 9 Nov 2000 11:23:33 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 From: David Shrader To: SIP List Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [SIP] Tag parameters on To header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 09 Nov 2000 14:19:12 -0500 Content-Transfer-Encoding: 7bit There is a minor inconsistancy in the bis draft. Section 6.43 (To) indicates that "The UAS or redirect server copies the To header field into its response, and MUST add a "tag" parameter." However, Section 11.2 (Callee Issues Response) indicates that "The response MUST copy the To, From, Call-ID, CSeq, and Via fields from the request. Additionally, the responding UAS MUST add teh tag parmaeter to the To field in the response if the request contained more than one Via header field." I can see that the tag parameter is not really necessary if there is no proxy, but the bis spec indicates otherwise in Section 6.43. Which is the "correct" way to do it? David ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 14:42: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 OAA07329 for ; Thu, 9 Nov 2000 14:42:49 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2170044357; Thu, 9 Nov 2000 13:41:08 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id E3CCE44346 for ; Thu, 9 Nov 2000 13:40:08 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Nov 9 14:38:28 EST 2000 Received: by lists.bell-labs.com (Postfix) id 1077344380; Thu, 9 Nov 2000 14:25:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 17D8F4437D for ; Thu, 9 Nov 2000 14:25:17 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA03305; Thu, 9 Nov 2000 13:25:12 -0600 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA03282; Thu, 9 Nov 2000 13:25:11 -0600 Message-ID: <3A0AFA19.8DE6A3B8@lucent.com> From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Internet Software and eServices Group X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] bye and record route References: <14858.58579.579036.850219@lohi.eng.telia.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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 09 Nov 2000 13:25:13 -0600 Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > section 4.2.4 bye says: > > If the INVITE request contained a Contact header, the callee SHOULD > send a BYE request to that address rather than the From address. > > if the invite had record route header, shouldn't the bye request be > send to its maddr instead? Right. When a UAC wants to send the request to it's next hop AND a Route list has been constructed, it'll examine the topmost Route and follow the rules listed in Section 1.4.2, "Locating a SIP Server" to figure out the destination. Step 1 in that section says, "If maddr parameter exists, it becomes the /destination address/ used ..." - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org Internet Software & eServices Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 14:48: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 OAA09246 for ; Thu, 9 Nov 2000 14:48:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5AC5B4434D; Thu, 9 Nov 2000 13:43:07 -0500 (EST) 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 4D47744346 for ; Thu, 9 Nov 2000 13:42:59 -0500 (EST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id TAA23336; Thu, 9 Nov 2000 19:43:52 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 09 Nov 2000 19:42:35 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 11:42:34 -0800 Message-ID: From: "Agarwal, Aseem" To: "'Dean Willis'" , "IETF SIP (E-mail)" Subject: RE: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 9 Nov 2000 11:42:06 -0800 Hi, I did not find a "Changes since last draft.." section. Can you please include this section or mention that no changes have been made. Just a suggestion, thanks, aseem -----Original Message----- From: Dean Willis [mailto:dwillis@dynamicsoft.com] Sent: Thursday, November 09, 2000 10:59 AM To: IETF SIP (E-mail) Subject: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt After one last very minor tweak, I believe we are ready to have a working-group last call on the ISUP-MIME draft, closing November 23. The latest rev has been sent to the drafts editor and can also be downloaded from: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt And remember, vote early, vote often. -- Dean Willis SIP WG co-chair. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 9 15: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 PAA04353 for ; Thu, 9 Nov 2000 15:54:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2CD2A44337; Thu, 9 Nov 2000 14:54:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 294BF44336 for ; Thu, 9 Nov 2000 14:53:35 -0500 (EST) Received: from zsc4c002.us.nortel.com by smtprch2.nortel.com; Thu, 9 Nov 2000 14:48:47 -0600 Received: from zsc4c006.us.nortel.com ([47.81.138.50]) by zsc4c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WSSWHQ04; Thu, 9 Nov 2000 12:52:57 -0800 Received: from long-pc.us.nortel.com (long-pc.corpwest.baynetworks.com [134.177.44.60]) by zsc4c006.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id V08581P0; Thu, 9 Nov 2000 12:52:54 -0800 Message-Id: <4.2.2.20001109125115.00ddbe40@zsc4c006.us.nortel.com> X-Sender: long@zsc4c006.us.nortel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: "Agarwal, Aseem" , "IETF SIP (E-mail)" From: "Lyndon Ong" Subject: RE: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 09 Nov 2000 12:53:57 -0800 Hi, The only change since draft 5 was to change the word "session" to "signal" in the "typical header" shown at the end of section 3.1 on page 3. This is an editorial correction, as draft 5 introduced the disposition type "signal", but I neglected to update the "typical header" accordingly. Cheers, L. Ong At 11:42 AM 11/9/2000 -0800, Agarwal, Aseem wrote: >Hi, > I did not find a "Changes since last draft.." section. Can you >please include this section or mention that no changes have been >made. > >Just a suggestion, >thanks, >aseem > >-----Original Message----- >From: Dean Willis >[mailto:dwillis@dynamicsoft.com] >Sent: Thursday, November 09, 2000 10:59 AM >To: IETF SIP (E-mail) >Subject: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt > > > >After one last very minor tweak, I believe we are ready to have a >working-group last call on the ISUP-MIME draft, closing November 23. > >The latest rev has been sent to the drafts editor and can also be downloaded >from: > >http >://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt > >And remember, vote early, vote often. > >-- >Dean Willis >SIP WG co-chair. > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com >/mailman/listinfo/sip > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >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 Nov 9 17:23:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29255 for ; Thu, 9 Nov 2000 17:23:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA6EF44337; Thu, 9 Nov 2000 16:23:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 58DB744336 for ; Thu, 9 Nov 2000 16:22:59 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id OAA17384; Thu, 9 Nov 2000 14:18:31 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 From: David Shrader To: Jonathan Rosenberg Cc: SIP List Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [SIP] Status of "serverfeatures" 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: Thu, 09 Nov 2000 17:14:10 -0500 Content-Transfer-Encoding: 7bit Jonathan, What is the status of which expired September? I can see that most of its capabilities are in the bis draft. However, I don't see anything related to the 421 code proposed in the draft. That is, if a server requires a particular extension (such as 100rel) but the client didn't include 100rel in a Supported header, how should it reject the request? In this particular example, the 100rel draft indicates "If the request did not include either a Supported or Require header indicating this feature, and the UAS wishes to send some provisional responses reliably, the UAS \SHOULD reject the initial request and include a Require header in the response, as per [4]" [4] is the "serverfeatures" draft. What code is used for this reject? David ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 17:26: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 RAA29946 for ; Thu, 9 Nov 2000 17:26:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ACA4544349; Thu, 9 Nov 2000 16:26:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 72D9644336 for ; Thu, 9 Nov 2000 16:25:48 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 4EE0B1E012 for ; Thu, 9 Nov 2000 17:25:42 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA22064 for ; Thu, 9 Nov 2000 17:25:41 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id RAA42422 for sip@lists.bell-labs.com; Thu, 9 Nov 2000 17:23:14 -0500 (EST) Message-Id: <200011092223.RAA42422@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: Re:[SIP] I-D ACTION:draft-ietf-sip-state-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 9 Nov 2000 17:23:14 -0500 (EST) Use of an added parameter on Record-Route was considered early as a way to do the equivalent to State headers (like about 3-4 IETF meetings ago) and was rejected. From our collective memory, there were several problems with overloading Route. Record-Route headers actually FORCE the subsequent messages to go to the proxy mentioned. We wanted something that was disjoint from routing, that would be usable if the message arrived there, but didn't force all the future messages to be routed thee. We also wanted the ability to insert multiple State headers in a message, and to attach State headers to requests for transfers (like when Refer-To is referring to an existing call that is to be replaced). There was also a good deal of confusion with using Route, that the Route header for a proxy was removed before the request was sent to it. Therefore the state information had to be off by one entry in the Record-Route list, and that it was different in the forward and reverse directions. Bill Marshall (on behalf of all the DCS team who contributed to this response) wtm@research.att.com -----original message----- From: "Anuraj Kunnummel Ennai" To: sip@lists.bell-labs.com Subject: Re:[SIP] I-D ACTION:draft-ietf-sip-state-00.txt Date: Thu, 09 Nov 2000 12:21:55 +0530 Hi , Went through the distributable call state draft. It is a move in the right direction as the proxies should be holding as little state information as possible in order to scale up. But it seems the idea of having a separate state header might not be needed. The nesting of state headers across proxies adds to complexity and overhead. Existing UA implementations cannot support state header. An alternative will be to use the Record-route option already defined. The proxy which adds a record route header(means the proxy is interested in keeping track of the call.)can add the state info duly encrypted as a parameter to record route header. Now only the proxy which inserted the record route header needs to interpret the state parameters. Note that record route is valid per call leg basis. Thus the proxy can selectively choose call legs which it is interested in. .The UA implementations need not worry as they are supposed to insert the Record-route header unchanged into the responses. As record - routing support is mandatory, this seems to be a better solution that needs very little changes. Also alleviates the need to live with one more header!!! This is what I feel from the first look...Or am I missing something? Thanks & regards Anuraj Ennai 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 Thu Nov 9 17:34: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 RAA02415 for ; Thu, 9 Nov 2000 17:34:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8FDD44337; Thu, 9 Nov 2000 16:32:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lists.bell-labs.com (Postfix) with ESMTP id 45A7244336 for ; Thu, 9 Nov 2000 16:31:53 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA12483 for ; Thu, 9 Nov 2000 15:11:07 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA28125 for ; Thu, 9 Nov 2000 15:11:06 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Thu, 9 Nov 2000 16:11:06 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED863D@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] VIA field Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 9 Nov 2000 16:10:58 -0600 It might be a basic question, sorry for that.. My understanding is that the "VIA" field serves two purposes: 1)Loop detection 2)Keeping proxies (which are part of the message forwarding path) in the response path. My question is: Does that mean also stateless proxies will be in the response path? If YES, perhaps it worths to enable a proxy to add a Boolean tag, which says: "Hey I am adding myself to the VIA list just for the sake of loop prevention, but count me out for the response thing" Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 9 19:05:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23120 for ; Thu, 9 Nov 2000 19:05:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C52CE44337; Thu, 9 Nov 2000 18:05:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 3912144336 for ; Thu, 9 Nov 2000 18:04:58 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA09420; Thu, 9 Nov 2000 19:04:32 -0500 (EST) Message-ID: <3A0B3B91.63D4AD82@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: David Shrader Cc: SIP List Subject: Re: [SIP] Tag parameters on To header 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, 09 Nov 2000 19:04:33 -0500 Content-Transfer-Encoding: 7bit David Shrader wrote: > > There is a minor inconsistancy in the bis draft. Section 6.43 (To) indicates > that "The UAS or redirect server copies the To header field into its > response, and MUST add a "tag" parameter." > > However, Section 11.2 (Callee Issues Response) indicates that "The response > MUST copy the To, From, Call-ID, CSeq, and Via fields from the request. > Additionally, the responding UAS MUST add teh tag parmaeter to the To field > in the response if the request contained more than one Via header field." > > I can see that the tag parameter is not really necessary if there is no > proxy, but the bis spec indicates otherwise in Section 6.43. > > Which is the "correct" way to do it? I've amended the text to remove the qualification. The more special cases we can get rid of, the better. -- 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 Nov 10 01:21: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 BAA13385 for ; Fri, 10 Nov 2000 01:21:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5901244337; Fri, 10 Nov 2000 00:21:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EB92A44336 for ; Fri, 10 Nov 2000 00:20:22 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01944; Fri, 10 Nov 2000 01:22:24 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y4H6>; Fri, 10 Nov 2000 01:18:38 -0500 Message-ID: From: Jonathan Rosenberg To: "'Sriram Parameswar'" , "'sip@lists.bell-labs.com'" Cc: Jonathan Rosenberg Subject: RE: [SIP] Caller Preferences and MESSAGE method 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, 10 Nov 2000 01:18:33 -0500 Caller preferences processing is really method independent. It would also be useful for SUBSCRIBE. I'll be sure to update the doc to make this clearer. -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: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Wednesday, November 08, 2000 8:51 PM To: 'sip@lists.bell-labs.com' Cc: Jonathan Rosenberg (E-mail) Subject: [SIP] Caller Preferences and MESSAGE method Hi, I think there is definite value in adding the MESSAGE method to the draft-ietf-sip-callerprefs-02. I see *all three* headers being of value to the MESSAGE method i.e. Accept-Contact, Reject-Contact and Request-Disposition. Some examples: 1. The sender of the IM could require that his Message be delivered only to a device with a class = "business". This could use the Accept-Contact header. 2. If you want to save your buddy valuable air-time charges you could send an IM with the following header Reject-Contact: sip:mybuddy@downtown.com;mobility="mobile" 3. You could use the Request-Disposition to ensure that the Contact list returned for the Message is tried sequentially. Thanks and Regards, Sriram Parameswar Nortel Networks _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 10 01:31:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19830 for ; Fri, 10 Nov 2000 01:31:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D5BF844340; Fri, 10 Nov 2000 00:31:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C0B7544336 for ; Fri, 10 Nov 2000 00:30:26 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01972; Fri, 10 Nov 2000 01:32:15 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y42C>; Fri, 10 Nov 2000 01:28:28 -0500 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] VIA field 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, 10 Nov 2000 01:28:20 -0500 > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Thursday, November 09, 2000 5:11 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] VIA field > > > It might be a basic question, sorry for that.. > > My understanding is that the "VIA" field serves two purposes: > 1)Loop detection > 2)Keeping proxies (which are part of the message forwarding > path) in the response path. > > My question is: Does that mean also stateless proxies will be > in the response path? Yes. > If YES, perhaps it worths to enable a proxy to add a Boolean > tag, which says: "Hey I am adding myself to the VIA list just > for the sake of loop prevention, but count me out for > the response thing" No. First and foremost, its not backwards compatible. Remember, SIP is already an RFC. It is not open season for "change SIP in all kinds of new ways". We are working to (1) fix bugs in the spec, (2) clarify things that are vague, (3) describe cases not already covered in the spec. If something is clearly defined and working correctly, I do not believe modifying it can be justified. -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 Nov 10 11:06:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19381 for ; Fri, 10 Nov 2000 11:06:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4079C44337; Fri, 10 Nov 2000 10:06:07 -0500 (EST) 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 B0F8744336 for ; Fri, 10 Nov 2000 10:05:36 -0500 (EST) Received: from softarmor.com (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id WAA09252; Fri, 10 Nov 2000 22:10:26 -0600 Message-ID: <3A0C1C66.38F3346F@softarmor.com> From: Dean Willis X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Summers Cc: "IETF SIP (E-mail)" Subject: Re: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt References: <69DEAC407D3B6A48AA71F5D09966F7DB41CCBB@mailhost.ttiworld.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 10 Nov 2000 10:03:50 -0600 Content-Transfer-Encoding: 7bit I believe that's RFC1806. -- Dean Kevin Summers wrote: > Which RFC defines Content-Disposition and its parameters? > > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: Thursday, November 09, 2000 12:59 PM > To: IETF SIP (E-mail) > Subject: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt > > After one last very minor tweak, I believe we are ready to have a > working-group last call on the ISUP-MIME draft, closing November 23. > > The latest rev has been sent to the drafts editor and can also be downloaded > from: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt > > And remember, vote early, vote often. > > -- > Dean Willis > SIP WG co-chair. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > > This footnote also confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > > www.inip.com > ********************************************************************** > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 10 11:25:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26310 for ; Fri, 10 Nov 2000 11:25:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 796E644340; Fri, 10 Nov 2000 10:25:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 0E34A44336 for ; Fri, 10 Nov 2000 10:24:19 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id KAA26767 for ; Fri, 10 Nov 2000 10:24:11 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eAAGM1k06805 for ; Fri, 10 Nov 2000 10:22:01 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA08510 for ; Fri, 10 Nov 2000 10:24:07 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA21513 for sip@lists.bell-labs.com; Fri, 10 Nov 2000 10:24:16 -0600 (CST) Message-Id: <200011101624.KAA21513@b04a24.exu.ericsson.se> To: sip@lists.bell-labs.com From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Ringback 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, 10 Nov 2000 10:24:16 -0600 (CST) Content-Transfer-Encoding: 7bit I now have an I-D out telling how to describe an appropriate ringback tone to be played to a caller for a SIP-initiated voice call; it does so by including new headers in the "180 Ringing" message. I currently plan to progress this as a non-workgroup informational draft, but am open to other suggestions. Let me know if this topic is of interest to you. Comments solicited. Abstract This document describes a mechanism by which an appropriate ringback tone may be played to the calling party when the called party's device is alerting. It is written specifcally to address the case where the Session Initiation Protocol (SIP) is used to initiate voice-over-IP calls. It also lists ringback characteristics for several countries. http://search.ietf.org/internet-drafts/draft-roach-voip-ringtone-00.txt -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 10 11:32:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28732 for ; Fri, 10 Nov 2000 11:32:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12EE444349; Fri, 10 Nov 2000 10:32:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 5416944336 for ; Fri, 10 Nov 2000 10:31:59 -0500 (EST) Received: from zsc4c002.us.nortel.com by smtprch2.nortel.com; Fri, 10 Nov 2000 10:27:02 -0600 Received: from zsc4c006.us.nortel.com ([47.81.138.50]) by zsc4c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WSSWJLKR; Fri, 10 Nov 2000 08:31:12 -0800 Received: from long-pc.us.nortel.com (long-pc.corpwest.baynetworks.com [134.177.44.60]) by zsc4c006.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id V0858F2B; Fri, 10 Nov 2000 08:31:11 -0800 Message-Id: <4.2.2.20001110083126.00c63630@zsc4c006.us.nortel.com> X-Sender: long@zsc4c006.us.nortel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Kevin Summers , "IETF SIP (E-mail)" From: "Lyndon Ong" Subject: RE: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt In-Reply-To: <69DEAC407D3B6A48AA71F5D09966F7DB41CCBB@mailhost.ttiworld.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: Fri, 10 Nov 2000 08:32:17 -0800 The bis draft references RFC1806 for the definition of the Content-Disposition header. Cheers, L. Ong At 11:27 AM 11/9/2000 -0800, Kevin Summers wrote: >Which RFC defines Content-Disposition and its parameters? > >-----Original Message----- >From: Dean Willis >[mailto:dwillis@dynamicsoft.com] >Sent: Thursday, November 09, 2000 12:59 PM >To: IETF SIP (E-mail) >Subject: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt > > > >After one last very minor tweak, I believe we are ready to have a >working-group last call on the ISUP-MIME draft, closing November 23. > >The latest rev has been sent to the drafts editor and can also be downloaded >from: > >http >://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt > >And remember, vote early, vote often. > >-- >Dean Willis >SIP WG co-chair. > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com >/mailman/listinfo/sip > >********************************************************************** >This email and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they >are addressed. If you have received this email in error please notify >the system manager. > >This footnote also confirms that this email message has been swept by >MIMEsweeper for the presence of computer viruses. > >www.inip.com >********************************************************************** > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com >/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 10 12: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 MAA12543 for ; Fri, 10 Nov 2000 12:12:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CFE454433E; Fri, 10 Nov 2000 11:12:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06s.us.nortel.com (unknown [47.140.48.50]) by lists.bell-labs.com (Postfix) with ESMTP id 7A25044336 for ; Fri, 10 Nov 2000 11:11:38 -0500 (EST) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Fri, 10 Nov 2000 10:44:35 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 10 Nov 2000 10:44:34 -0500 Message-ID: <28560036253BD41191A10000F8BCBD1102B9EEB5@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Kevin Summers , "IETF SIP (E-mail)" Subject: RE: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt 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: Fri, 10 Nov 2000 10:44:25 -0500 It's in the base SIP spec. > -----Original Message----- > From: Kevin Summers [mailto:Kevin.Summers@ttimail.com] > Sent: Thursday, November 09, 2000 2:27 PM > To: IETF SIP (E-mail) > Subject: RE: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt > > > Which RFC defines Content-Disposition and its parameters? > > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: Thursday, November 09, 2000 12:59 PM > To: IETF SIP (E-mail) > Subject: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt > > > > > After one last very minor tweak, I believe we are ready to have a > working-group last call on the ISUP-MIME draft, closing November 23. > > The latest rev has been sent to the drafts editor and can > also be downloaded > from: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt > > > And remember, vote early, vote often. > > -- > Dean Willis > SIP WG co-chair. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > > This footnote also confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > > www.inip.com > ********************************************************************** > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 10 12:59:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29014 for ; Fri, 10 Nov 2000 12:59:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CED494433E; Fri, 10 Nov 2000 11:59:06 -0500 (EST) 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 569AA44336 for ; Fri, 10 Nov 2000 11:58:16 -0500 (EST) Received: from mobilerain.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3.mobilerain.com (8.9.3/8.9.3) with ESMTP id KAA14540; Fri, 10 Nov 2000 10:00:28 -0800 Message-ID: <3A0C37BC.2D725B95@mobilerain.com> From: Bobby Sardana Organization: MobileRain Technologies, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Summers Cc: "IETF SIP (E-mail)" Subject: Re: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt References: <69DEAC407D3B6A48AA71F5D09966F7DB41CCBB@mailhost.ttiworld.com> Content-Type: multipart/mixed; boundary="------------FC61928E5FE1992B8712FC98" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 10 Nov 2000 10:00:28 -0800 This is a multi-part message in MIME format. --------------FC61928E5FE1992B8712FC98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings: Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field (RFC 2183) Regards, Bobby.Sardana@mobilerain.com Kevin Summers wrote: > Which RFC defines Content-Disposition and its parameters? > > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: Thursday, November 09, 2000 12:59 PM > To: IETF SIP (E-mail) > Subject: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt > > After one last very minor tweak, I believe we are ready to have a > working-group last call on the ISUP-MIME draft, closing November 23. > > The latest rev has been sent to the drafts editor and can also be downloaded > from: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt > > And remember, vote early, vote often. > > -- > Dean Willis > SIP WG co-chair. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > > This footnote also confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > > www.inip.com > ********************************************************************** > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------FC61928E5FE1992B8712FC98 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 --------------FC61928E5FE1992B8712FC98-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 10 14: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 OAA09154 for ; Fri, 10 Nov 2000 14:44:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 290CD44337; Fri, 10 Nov 2000 13:44:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id 08F2144336 for ; Fri, 10 Nov 2000 13:43:46 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA08107 for ; Fri, 10 Nov 2000 12:43:36 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA25043 for ; Fri, 10 Nov 2000 12:43:36 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 10 Nov 2000 13:43:35 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8645@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" Subject: FW: [SIP] VIA field 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: Fri, 10 Nov 2000 13:43:28 -0600 Jonathan No problem at all. It was just an idea to have in the back of the mind for future studies/work. I know how important it is to retain backward compatibility and to handle the things that you have mentioned first, only then to think of ideas like that good or bad as they may be. Uri -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, November 10, 2000 12:28 AM To: 'Baniel Uri-CUB001'; 'sip@lists.bell-labs.com' Subject: RE: [SIP] VIA field > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Thursday, November 09, 2000 5:11 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] VIA field > > > It might be a basic question, sorry for that.. > > My understanding is that the "VIA" field serves two purposes: > 1)Loop detection > 2)Keeping proxies (which are part of the message forwarding > path) in the response path. > > My question is: Does that mean also stateless proxies will be > in the response path? Yes. > If YES, perhaps it worths to enable a proxy to add a Boolean > tag, which says: "Hey I am adding myself to the VIA list just > for the sake of loop prevention, but count me out for > the response thing" No. First and foremost, its not backwards compatible. Remember, SIP is already an RFC. It is not open season for "change SIP in all kinds of new ways". We are working to (1) fix bugs in the spec, (2) clarify things that are vague, (3) describe cases not already covered in the spec. If something is clearly defined and working correctly, I do not believe modifying it can be justified. -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 Nov 10 16: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 QAA21580 for ; Fri, 10 Nov 2000 16:54:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57C2A44337; Fri, 10 Nov 2000 15:54:07 -0500 (EST) 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 15B9044336 for ; Fri, 10 Nov 2000 15:53:36 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id PAA02951; Fri, 10 Nov 2000 15:54:51 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Fri, 10 Nov 2000 15:48:20 -0600 Message-ID: From: "Culpepper, Bert" To: "Adam B. Roach" , sip@lists.bell-labs.com Subject: RE: [SIP] Ringback draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 10 Nov 2000 15:48:19 -0600 I think the ability to specify the ringback tone characteristics is useful and expect some to find it desirable. The (somewhat subtle) aspect of the draft that I feel is also useful is that the device on the edge of the SIP network (towards the caller) is responsible for providing ringback tone. In the PSTN, the switch at the edge of the network (towards the callee) provides ringback. In a PSTN-IP network where the call terminates in the IP network, the device responsible for providing ringback is the ingress gateway to the IP network IMO. I've found that which device provides ringback is unclear to some when discussing PSTN-IP interworking. I realize the aspect I described is not the focus of your draft but the topic does interest me :) Regards, Bert -----Original Message----- From: Adam B. Roach [mailto:Adam.Roach@Ericsson.com] Sent: Friday, November 10, 2000 11:24 AM To: sip@lists.bell-labs.com Subject: [SIP] Ringback draft I now have an I-D out telling how to describe an appropriate ringback tone to be played to a caller for a SIP-initiated voice call; it does so by including new headers in the "180 Ringing" message. I currently plan to progress this as a non-workgroup informational draft, but am open to other suggestions. Let me know if this topic is of interest to you. Comments solicited. Abstract This document describes a mechanism by which an appropriate ringback tone may be played to the calling party when the called party's device is alerting. It is written specifcally to address the case where the Session Initiation Protocol (SIP) is used to initiate voice-over-IP calls. It also lists ringback characteristics for several countries. http://search.ietf.org/internet-drafts/draft-roach-voip-ringtone-00.txt -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 10 17:08: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 RAA26172 for ; Fri, 10 Nov 2000 17:08:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB1A744354; Fri, 10 Nov 2000 16:05:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3F7D044337 for ; Fri, 10 Nov 2000 09:04:04 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA03885 for ; Fri, 10 Nov 2000 10:06:18 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y44J>; Fri, 10 Nov 2000 10:02:31 -0500 Message-ID: From: Dean Willis To: "IETF 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] Slot-request tracking page for SIPWG, IETF49 established Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 10 Nov 2000 10:02:29 -0500 I am tracking slot requests for SIPWG at: http://www.softarmor.com/sipwg/meets/IETF49/requests.htm If you make a request and don't see a timely response, please ping me. BTW, I'll be hiding from the world during 17Nov-27Nov. At least I'll be operating with reduced bandwidth during that interval. -- Dean Willis SIP WG cochair _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 10 17:10: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 RAA26907 for ; Fri, 10 Nov 2000 17:10:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 73B8C4435A; Fri, 10 Nov 2000 16:05:23 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3FD9744336 for ; Fri, 10 Nov 2000 10:02:28 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA04759; Fri, 10 Nov 2000 11:04:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y4Z7>; Fri, 10 Nov 2000 11:00:53 -0500 Message-ID: From: Dean Willis To: "'Agarwal, Aseem'" , "IETF SIP (E-mail)" Subject: RE: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 10 Nov 2000 11:00:52 -0500 My apologies. I believe only one word was changed between 5 and 6 -- changed "session" to "signal" on page 3. But you are right, it should be mentioned in "Changes". -- Dean -----Original Message----- From: Agarwal, Aseem [mailto:aseem@trillium.com] Sent: Thursday, November 09, 2000 1:42 PM To: 'Dean Willis'; IETF SIP (E-mail) Subject: RE: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt Hi, I did not find a "Changes since last draft.." section. Can you please include this section or mention that no changes have been made. Just a suggestion, thanks, aseem -----Original Message----- From: Dean Willis [mailto:dwillis@dynamicsoft.com] Sent: Thursday, November 09, 2000 10:59 AM To: IETF SIP (E-mail) Subject: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt After one last very minor tweak, I believe we are ready to have a working-group last call on the ISUP-MIME draft, closing November 23. The latest rev has been sent to the drafts editor and can also be downloaded from: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt And remember, vote early, vote often. -- Dean Willis SIP WG co-chair. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 10 17:51:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08020 for ; Fri, 10 Nov 2000 17:51:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E26CE4433B; Fri, 10 Nov 2000 16:51:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 20FE544336 for ; Fri, 10 Nov 2000 16:50:26 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA12702; Fri, 10 Nov 2000 17:50:10 -0500 (EST) Message-ID: <3A0C7BA1.3B0BC3D8@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Ringback draft References: <200011101624.KAA21513@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 10 Nov 2000 17:50:09 -0500 Content-Transfer-Encoding: 7bit I would suggest making the location information somewhat more generic, as this is useful for other applications, as pointed out in http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-911-01.txt Also, there are related efforts in other areas that address the location problem. It would seem appropriate to take these into consideration, in the "tradition" of trying to leverage HTTP/web-related work going on, as well as avoiding too many telephony-only extensions. http://www.ietf.org/internet-drafts/draft-daviel-http-geo-header-02.txt http://www.ietf.org/internet-drafts/draft-costanzo-dns-gl-03.txt (The latter is obviously DNS, but the labeling may be applicable, as shown in the 911 draft.) Users can obviously omit details they'd rather not specify or don't know. Also, there's an obvious relationship to RFC 2833 (RTP "tones") that should be explored. Note also that you could use the Alert-Info for the same purpose, by providing an external (cached) reference to whatever national tones you'd like the caller to hear. -- 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 Nov 10 20:06:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07250 for ; Fri, 10 Nov 2000 20:06:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 26DD04433B; Fri, 10 Nov 2000 19:06:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id 0C7C744336 for ; Fri, 10 Nov 2000 19:05:03 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Nov 2000 17:02:26 -0800 Message-ID: <6374EFC78443D41197DD00508B5C35DD01A44EE6@rwcxch02.clarent.com> From: Jean-Francois Mule To: sip-mib@egroups.com, "Henning G. Schulzrinne" Cc: drwalker@ss8networks.com, joon_maeng@vtel.com, sip@lists.bell-labs.com Subject: RE: [sip-mib] Re: [SIP] Some comments on the SIP MIB - configurat ion of security options (draft-ietf-sip-mib-01.txt) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 10 Nov 2000 17:02:25 -0800 OK - I agree it can get complex and it is certainly preferable to avoid this in the MIB. The object sipProxyAuthMethod then refers to the capabilities: - the ability of the SIP entity to perform Authentication, and, - in cases when authentication is performed, it specifies the method (capabilities such as the supported algorithm(s) are in some subsequent objects). See comments below. Jean-Francois Mule. ------------------------- Kevin Lingle wrote: > that said, it does look like the value 'none' and it's > current description > go beyond that intended purpose. the description says 'none' means no > authentication will be performed. perhaps that is a point of > confusion. > maybe 'none' should be changed to 'unknown' and the > description altered > to not imply anything about authentication being performed? comments? If we agree with the definition given above, I'd rather keep none with this description: "This object specifies the authentication method that the SIP entity supports to authenticate request originators. none(1) : no authentication is supported. basic(2) : the basic authentication mechanism is supported. digest(3) : the digest authentication mechanism is supported." > additionally, we recently got a request to alter the syntax of this > object so that multiple auth methods could be in play at once. that > would be done by making the object's syntax BITS rather than INTEGER. Yes, and this request confirms the intent of the var: capabilities for the supported authentication mechanims. > you could turn on bits for any combination of 'basic', 'digest', or > 'pgp'. the value of 0 would likely imply 'none'. > so while we're on the subject are there any comments regarding this > proposed change (ie, to specify multiple auth methods)? > i am currently planning on making this change, so if there are strong > arguments against i'd like to hear them now rather than later. YES. > > kevin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 10 23:49:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01966 for ; Fri, 10 Nov 2000 23:49:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FA184433B; Fri, 10 Nov 2000 22:49:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 9660044336 for ; Fri, 10 Nov 2000 22:48:22 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id UAA06122; Fri, 10 Nov 2000 20:43:45 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SIP] Ringback draft From: David Shrader To: SIP List Cc: "Adam B. Roach" Message-ID: In-Reply-To: <3A0C7BA1.3B0BC3D8@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 10 Nov 2000 23:39:09 -0500 Content-Transfer-Encoding: 7bit Henning has a good point about leveraging the location work going on elsewhere in the IETF. One question I then have is should the ringback tone be based on my current location or rather on my home location so that the caller hears what they expect to hear. On the other hand, I always found the different tones in different countries confusing. One advantage to not specifying them is that the originator has his system customized for his location and he hears a consistent set of tones regardless of where the callee is located. I actually don't really like the idea of the originating side reconstructing the ring pattern for the terminating side in such a specific manner. The use of the Alert-Info: header provides an ideal solution to the problem. If we are going to all this trouble for the callee to tell the calling party what to hear, maybe its better to send a 183 and include the tones via RTP. Maybe this is something the PSTN did right :-) ---------------------------- David Shrader Master Consultant, Inc. "Solution Oriented Engineering" dshrader@master-consultant.com http://www.EyeForTheFuture.com > From: "Henning G. Schulzrinne" > Organization: Dept. of Computer Science, Columbia University > Date: Fri, 10 Nov 2000 17:50:09 -0500 > To: "Adam B. Roach" > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Ringback draft > > I would suggest making the location information somewhat more generic, > as this is useful for other applications, as pointed out in > > http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-911-01.txt > > Also, there are related efforts in other areas that address the location > problem. It would seem appropriate to take these into consideration, in > the "tradition" of trying to leverage HTTP/web-related work going on, as > well as avoiding too many telephony-only extensions. > > http://www.ietf.org/internet-drafts/draft-daviel-http-geo-header-02.txt > > http://www.ietf.org/internet-drafts/draft-costanzo-dns-gl-03.txt > > (The latter is obviously DNS, but the labeling may be applicable, as > shown in the 911 draft.) > > Users can obviously omit details they'd rather not specify or don't > know. > > Also, there's an obvious relationship to RFC 2833 (RTP "tones") that > should be explored. Note also that you could use the Alert-Info for the > same purpose, by providing an external (cached) reference to whatever > national tones you'd like the caller to hear. > -- > 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 Nov 11 01:00:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22782 for ; Sat, 11 Nov 2000 01:00:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0891D4433B; Sat, 11 Nov 2000 00:00:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id A2AC344336 for ; Fri, 10 Nov 2000 23:59:20 -0500 (EST) Received: from CJNOTE650 ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with SMTP id G3UITI00.URY; Fri, 10 Nov 2000 21:48:54 -0800 From: "Cullen Jennings" To: "SIP List" Cc: "Adam B. Roach" Subject: RE: [SIP] Ringback draft 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: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 10 Nov 2000 21:59:35 -0800 Content-Transfer-Encoding: 7bit One of the nice parts of sending the Ringback tone in the media channel is that the media channel is established (at least in one direction) before the callee picks up. This ensure that the first "Hello" of the person answering the phone is not cut off. This early set up of RTP is probably even more important when you consider that perhaps QoS and/or encryption are also being set up for the RTP connection. If the issue with ring back via RTP is that it wastes bandwidth, I imagine some special "Ringback tone" style RTP packets could be defined. Cullen Jennings _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 11 09:47: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 JAA22771 for ; Sat, 11 Nov 2000 09:47:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D20B4433B; Sat, 11 Nov 2000 08:47:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by lists.bell-labs.com (Postfix) with ESMTP id D457644336 for ; Sat, 11 Nov 2000 08:46:50 -0500 (EST) Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id JAA20325; Sat, 11 Nov 2000 09:46:37 -0500 (EST) Message-ID: <3A0D5BC9.BA52328E@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings Cc: SIP List , "Adam B. Roach" Subject: Re: [SIP] Ringback draft 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: Sat, 11 Nov 2000 09:46:33 -0500 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > One of the nice parts of sending the Ringback tone in the media channel is > that the media channel is established (at least in one direction) before the > callee picks up. This ensure that the first "Hello" of the person answering > the phone is not cut off. This early set up of RTP is probably even more > important when you consider that perhaps QoS and/or encryption are also > being set up for the RTP connection. > > If the issue with ring back via RTP is that it wastes bandwidth, I imagine > some special "Ringback tone" style RTP packets could be defined. Well, RFC 2833 already allows to define any tone you want. You can even do harmonies. All we need is a MIDI-to-RTP translator... In general, I have to admit that I find the notion of having to replicate the called country's tones a bit too much of the "it might be a strange artifact of the phone system, but we have to replicate every bit of it" syndrom. I can see the advantage that if I'm traveling, to hear familiar tone sequences regardless of my location. However, that should be done by configuring either my portable device or, temporarily, the Internet pay phone to play familiar sounds. I can't say that I've been confused or comforted by "foreign" ringback; the problem tends to be more trying to understand the Swedish version of "this number has been disconnected". More confusing than ringback are usually the various busy and fast-busy tones. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 11 11:57:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28007 for ; Sat, 11 Nov 2000 11:57:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0065A4433B; Sat, 11 Nov 2000 10:57:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 9819E44336 for ; Sat, 11 Nov 2000 10:56:54 -0500 (EST) Received: from po133.warszawa.cvx.ppp.tpnet.pl ([213.76.110.133]:1860 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Sat, 11 Nov 2000 17:41:44 +0100 Message-ID: <3A0D765F.5006DA90@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP List Subject: Re: [SIP] Ringback draft References: <3A0D5BC9.BA52328E@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 11 Nov 2000 17:39:59 +0100 Content-Transfer-Encoding: 7bit First off, I have to admit that I didn't explored RFC 2833. But looking thru the "Ringback draft" thread of the SIP list, I thought about payments, if we consider network with payment policy. So my appologies for, perhaps, improper question: Who will be paying for transmission of RTP ringback tones if transaction is not succesfuly completed (e.g. rejected by callee). As i suppose, ringback RTP/UDP requires much more bandwith than SIP messages/UDP, and should not be passed over ?... Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 11 16:58:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02771 for ; Sat, 11 Nov 2000 16:58:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A6AD344338; Sat, 11 Nov 2000 15:58:07 -0500 (EST) 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 8BF9544336 for ; Sat, 11 Nov 2000 15:57:44 -0500 (EST) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Sat, 11 Nov 2000 13:55:11 -0800 Message-ID: <021801c04c2a$c8115390$3a0514ac@sbarber2k> From: "Simon Barber" To: "\"Piotr S. Kossowski\"" Cc: "'Sip@Lists. Bell-Labs. Com'" References: <3A0D5BC9.BA52328E@cs.columbia.edu> <3A0D765F.5006DA90@elka.pw.edu.pl> Subject: Re: [SIP] Ringback draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 11 Nov 2000 14:00:19 -0800 Content-Transfer-Encoding: 7bit SIP calls, where the endpoint is IP based will probably not be charged for (the phone companies will slowly wake up to this fact), unless the call involves a gateway to the PSTN, special service, or some QoS mechanism. Simon Barber ----- Original Message ----- From: ""Piotr S. Kossowski"" Newsgroups: ietf.sip-wg Sent: Saturday, November 11, 2000 8:39 AM Subject: Re: [SIP] Ringback draft > > First off, I have to admit that I didn't explored RFC 2833. > But looking thru the "Ringback draft" thread of the SIP list, I thought > about payments, if we consider network with payment policy. > So my appologies for, perhaps, improper question: Who will be paying for > transmission of RTP ringback tones if transaction is not succesfuly > completed (e.g. rejected by callee). As i suppose, ringback RTP/UDP > requires much more bandwith than SIP messages/UDP, and should not be > passed over ?... > > Piotr > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 11 18:38: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 SAA24234 for ; Sat, 11 Nov 2000 18:38:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DD05B44338; Sat, 11 Nov 2000 17:38:06 -0500 (EST) 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 00B6144336 for ; Sat, 11 Nov 2000 17:37:41 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G3V00G01WAD7O@firewall.mcit.com> for sip@lists.bell-labs.com; Sat, 11 Nov 2000 23:37:25 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G3V00BG2WAD4G@firewall.mcit.com>; Sat, 11 Nov 2000 23:37:25 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G3V00701W32KU@pmismtp04.wcomnet.com>; Sat, 11 Nov 2000 23:33:02 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G3V00701W30KK@pmismtp04.wcomnet.com>; Sat, 11 Nov 2000 23:33:02 +0000 (GMT) Received: from hsinnreich ([166.46.19.12]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G3V00DI4W2LNS@pmismtp04.wcomnet.com>; Sat, 11 Nov 2000 23:32:52 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] Ringback draft In-reply-to: <3A0D765F.5006DA90@elka.pw.edu.pl> To: "Piotr S. Kossowski" , SIP List 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=us-ascii 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: Sat, 11 Nov 2000 17:37:23 -0600 Content-Transfer-Encoding: 7bit Payment policy that is user friendly would prevent charging for tones. IMHO, charging for very short intervalls of time, such as the beginning of a conversation, say for less than 30 seconds is more expensive to the service provider than not charging at all for such short transients. Even if a gateway is involved, charging for 10s of seconds does not seem to make sense, given present ever dropping LD prices. Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Piotr S. Kossowski Sent: Saturday, November 11, 2000 10:40 AM To: SIP List Subject: Re: [SIP] Ringback draft First off, I have to admit that I didn't explored RFC 2833. But looking thru the "Ringback draft" thread of the SIP list, I thought about payments, if we consider network with payment policy. So my appologies for, perhaps, improper question: Who will be paying for transmission of RTP ringback tones if transaction is not succesfuly completed (e.g. rejected by callee). As i suppose, ringback RTP/UDP requires much more bandwith than SIP messages/UDP, and should not be passed over ?... Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 12 17:18: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 RAA21874 for ; Sun, 12 Nov 2000 17:18:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2499844338; Sun, 12 Nov 2000 16:18:08 -0500 (EST) 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 A6B2144336 for ; Sun, 12 Nov 2000 16:17:54 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G3X00M01N9NB4@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 12 Nov 2000 22:17:48 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G3X00JBIN9NGY@firewall.mcit.com>; Sun, 12 Nov 2000 22:17:47 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G3X00H01N2CN3@pmismtp04.wcomnet.com>; Sun, 12 Nov 2000 22:13:24 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G3X00H01N2AMN@pmismtp04.wcomnet.com>; Sun, 12 Nov 2000 22:13:24 +0000 (GMT) Received: from hsinnreich ([166.44.57.241]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G3X00AABN1LLB@pmismtp04.wcomnet.com>; Sun, 12 Nov 2000 22:13:13 +0000 (GMT) From: Henry Sinnreich In-reply-to: To: adam.roach@ericsson.com, "IETF SIP (E-mail)" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [SIP] SIP ringback tone Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 12 Nov 2000 16:17:44 -0600 Content-Transfer-Encoding: 7bit The draft on "Ringback tones in SIP-Based Telephony" shows impressive work on preserving legacy country specific ring back tones. I wonder if we would not be better of by adding a SIP Ringback Tone ================= With some optional fields where service providers could add innovative greetings. Henry Henry Sinnreich WorldCom 400 International Parkway, Richardson, Texas, 75081 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 01:50: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 BAA08692 for ; Mon, 13 Nov 2000 01:50:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 38B5544338; Mon, 13 Nov 2000 00:50:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web1401.mail.yahoo.com (web1401.mail.yahoo.com [128.11.23.165]) by lists.bell-labs.com (Postfix) with SMTP id BD2B244336 for ; Mon, 13 Nov 2000 00:49:59 -0500 (EST) Received: (qmail 7455 invoked by uid 60001); 13 Nov 2000 06:49:53 -0000 Message-ID: <20001113064953.7454.qmail@web1401.mail.yahoo.com> Received: from [206.82.141.26] by web1401.mail.yahoo.com; Sun, 12 Nov 2000 22:49:53 PST From: zeeshan razzaque To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Multiple Aliases Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 12 Nov 2000 22:49:53 -0800 (PST) Hi, Can my UA be registered with multiple Aliases? (analogous to having a single mailbox for different email addresses) Zeeshan. __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 04:13:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18887 for ; Mon, 13 Nov 2000 04:13:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A6AC744338; Mon, 13 Nov 2000 03:13:07 -0500 (EST) 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 543CF44336 for ; Mon, 13 Nov 2000 03:12:13 -0500 (EST) 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 eAD9C5Z20451; Mon, 13 Nov 2000 10:12:05 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id eAD9C4518560; Mon, 13 Nov 2000 10:12:05 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id KAA22426; Mon, 13 Nov 2000 10:12:00 +0100 (MET) Message-ID: <3A0FB05E.671E3F99@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Cc: Jo Hornsby Subject: Re: [SIP] Identification problem References: <8ubolu$dqp$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 10:11:58 +0100 Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > If, OTOH, we are looking at backwards-compatibility from a "work > with existing SIP Implementations" standpoint, then I have to say > that so much of Record-Route wouldn't have worked anyway (the > spec says nothing about building Route:s in the callee -> caller > direction), is it really worth worrying? > > With this approach, we can write into bis, say, that the called > UA, when forming requests, renames all "uri" parameters to > "original-uri"; and appends a new "uri" parameter with the value > of the Contact:/From:. > > We now have the resilience that Jonathan was addressing (thread: > "failure of proxy), since each proxy along the Route can see > the final destination. And also, if the request spiralled, > we know where on the Route we are (since we have retained the > original Request-URIs, too). > > Now I know that this is a significant change, but as far as I can > tell, realistically, no proxy will as yet have been able to > Record-Route properly and/or remain call stateful, because we > are still finding bugs. Thus it doesn't seem as if there can be > real objections to making such a changes, since hopefully they > are changes towards having a fully-working mechanism (okay, I > guess we think it works now, but it can't be more than 3 months > since we spotted that Record-Route: can break in the reverse > direction when a request has spiralled; how mature can > implementations possibly be?) > I thought I were the only one having these thoughts. This is the reason why I started to suggest simplifications to SIP some months ago. It was quite obvious that the protocol was not complete at that time (it's not even complete today). So to argue that a specification that is not complete and still contain major bugs have to be backwards compatible is very strange to me. But I guess I have to live with that ?? The kind of solution I would like to have to this problem is a change of the ROUTE behaviour so it behaves like VIA i.e. you remove your "own" entry from the list instead of removing the next servers entry. In this way it would be possible to add any RECORD-ROUTE parameter and get it back later in ROUTE (if the client copies the whole RECORD-ROUTE into ROUTE). This would make the state draft obsolete and it would also solve my problem with identifying the call state machine. Since this change is a pure semantic change I see no reason why it can't be done like this ;-). The only syntax change needed is to add a 'hostport' parameter to RECORD-ROUTE instead of maddr as Jonathan pointed out. Since this is needed for TEL-URI etc. this parameter has to be added but I would prefere to ALWAYS use this new parameter instead of sometimes using maddr. /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 Nov 13 06:19: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 GAA24261 for ; Mon, 13 Nov 2000 06:19:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 54D8344350; Mon, 13 Nov 2000 05:19:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id AEBF844336 for ; Mon, 13 Nov 2000 05:18:24 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 13 Nov 2000 11:18:18 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA04228; Mon, 13 Nov 2000 12:16:37 +0100 (BST) From: "Jo Hornsby" To: "zeeshan razzaque" , Subject: RE: [SIP] Multiple Aliases Message-ID: <004b01c04d63$2f9726f0$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: <20001113064953.7454.qmail@web1401.mail.yahoo.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 11:16:36 -0000 Content-Transfer-Encoding: 7bit > Hi, Can my UA be registered with multiple Aliases? > (analogous to having a single mailbox for different > email addresses) Very much so (the only thing preventing this would be a lack of Service Providers/Registrars willing to let you do this). - 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 Nov 13 06:33: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 GAA01723 for ; Mon, 13 Nov 2000 06:33:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 48D0544358; Mon, 13 Nov 2000 05:33:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id E31E844336 for ; Mon, 13 Nov 2000 05:32:44 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 03:33:36 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henry Sinnreich'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP ringback tone 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, 13 Nov 2000 03:33:35 -0800 Henry, Innovative ringback greetings definitely seem like a case for an early media to me. As an aside, many people still seem to erroroneously think that 183 Session Progress should be used for early-media ring-back. 180 Ringing with SDP should be used for ringback purposes, 183 with SDP should only be used for call progress messages (ie, not alerting the user). I still think this needs to be made clearer in the spec! Cheers, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > Sent: Monday, November 13, 2000 6:18 AM > To: adam.roach@ericsson.com; IETF SIP (E-mail) > Subject: [SIP] SIP ringback tone > > > The draft on "Ringback tones in SIP-Based Telephony" shows > impressive work > on preserving legacy country specific ring back tones. I > wonder if we would > not be better of by adding a > > SIP Ringback Tone > ================= > > With some optional fields where service providers could add innovative > greetings. > > Henry > > Henry Sinnreich > WorldCom > 400 International Parkway, > Richardson, Texas, 75081 > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 13 06: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 GAA13133 for ; Mon, 13 Nov 2000 06:54:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8701A4435D; Mon, 13 Nov 2000 05:54:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A9ABA44357 for ; Mon, 13 Nov 2000 05:53:28 -0500 (EST) Received: from dynamicsoft.com ([212.120.151.69]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA01867; Mon, 13 Nov 2000 06:55:04 -0500 (EST) Message-ID: <3A0FD5BC.7E76D609@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manish S. Jalan" Cc: jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP provisioning Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 13 Nov 2000 11:51:24 +0000 Content-Transfer-Encoding: 7bit Manish, Thank you for your query. It is a very good question indeed. The rational behind only having a get method for ListeningPoints is that the scope JAIN SIP API does not include provisioning - the API assumes the SIP stack has been set up previously by some other means. Currently this implies the use of proprietary methods for setting/adding ListeningPoints. However there is a JMX-based JAIN OAM API (which currently handles SS7 stacks). The plan is to extend or provide a similar OAM API for the JAIN IP protocols. Admittedly OAM is a lot less complicated for SIP stacks than SS7 stacks, and there is a very strong case for just including the addListeningPoint method to the JainSipStack interface, but this was deemed inconsistent with other JAIN protocol API's. Note, personally I would prefer leaving the OAM API in the SS7 domain, and adding the necessary methods (only one in SIP!) to the Stack objects in IP protocol APIs. Regards, Chris Harris Subject: Seeking clarification on JainSipStack Interface Date: 13 Nov 2000 04:00:04 -0000 From: "Manish S. Jalan" To: "JAIN-SIP-interest@sun.com" Interface JainSipStack defines methods to create providers, get an array of Listening points available to the stack, etc. The default listening point may be a combination localhost and standard sip port 5060. Now one may want to have additional listening points(on some other ports). Hence not only should the JainSipStack define a get method for the ListeningPoints list, but should also have one to add to the list of ListeningPoints. I may be wrong somewhere, as definitely there must have been some rational behind, only defining a get method, and not a add method. Kindly, clarify the rational. But if I am correct, then please include addListeningPoint() method in the JainSipStack interface. Regards, -Manish S. Jalan _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com Participate in crazy auctions at http://auctions.rediff.com/auctions/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 07:28: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 HAA00974 for ; Mon, 13 Nov 2000 07:28:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 60D2C44350; Mon, 13 Nov 2000 06:28:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id A010344336 for ; Mon, 13 Nov 2000 06:27:17 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 13 Nov 2000 12:27:11 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA04891; Mon, 13 Nov 2000 13:25:43 +0100 (BST) From: "Jo Hornsby" To: , Subject: RE: [SIP] Identification problem Message-ID: <004f01c04d6c$d74c6a50$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: <3A0FB05E.671E3F99@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 12:25:43 -0000 Content-Transfer-Encoding: 7bit Bertil Engelholm wrote: > > > If, OTOH, we are looking at backwards-compatibility from a "work > > with existing SIP Implementations" standpoint, then I have to say > > that so much of Record-Route wouldn't have worked anyway (the > > spec says nothing about building Route:s in the callee -> caller > > direction), is it really worth worrying? > > > > With this approach, we can write into bis, say, that the called > > UA, when forming requests, renames all "uri" parameters to > > "original-uri"; and appends a new "uri" parameter with the value > > of the Contact:/From:. > > > > We now have the resilience that Jonathan was addressing (thread: > > "failure of proxy), since each proxy along the Route can see > > the final destination. And also, if the request spiralled, > > we know where on the Route we are (since we have retained the > > original Request-URIs, too). > > > > Now I know that this is a significant change, but as far as I can > > tell, realistically, no proxy will as yet have been able to > > Record-Route properly and/or remain call stateful, because we > > are still finding bugs. Thus it doesn't seem as if there can be > > real objections to making such a changes, since hopefully they > > are changes towards having a fully-working mechanism (okay, I > > guess we think it works now, but it can't be more than 3 months > > since we spotted that Record-Route: can break in the reverse > > direction when a request has spiralled; how mature can > > implementations possibly be?) > > > > I thought I were the only one having these thoughts. This is > the reason why I started to suggest simplifications to SIP some > months ago. It was quite obvious that the protocol was not > complete at that time (it's not even complete today). So > to argue that a specification that is not complete and still > contain major bugs have to be backwards compatible is very > strange to me. But I guess I have to live with that ?? I'm not sure that this is fair. The protocol may fall slightly short of being complete even today (although I might argue that it is more our understanding that is uncomplete; the protocol _may_ be spot on already), but where does the "major bugs" come from? > The kind of solution I would like to have to this problem is > a change of the ROUTE behaviour so it behaves like VIA i.e. > you remove your "own" entry from the list instead of removing > the next servers entry. In this way it would be possible to > add any RECORD-ROUTE parameter and get it back later in ROUTE > (if the client copies the whole RECORD-ROUTE into ROUTE). This > would make the state draft obsolete and it would also solve > my problem with identifying the call state machine. Since > this change is a pure semantic change I see no reason why > it can't be done like this ;-). I don't buy this at all. And championing it on the basis that it's purely a semantic change seems a little weak, at best. In fact, I would argue that such a potentially subtle change (older implementations would think they were doing the Right Thing, while devices downstream would be suffering major lossage) is dangerous. I would consider it preferable to do something like inventing Record-Route2:/Route2:, since then at least the intent is clear all the way, 2543 or no. (Please note that I'm not proposing we do this.) > The only syntax change needed is to add a 'hostport' > parameter to RECORD-ROUTE instead of maddr as Jonathan > pointed out. Since this is needed for TEL-URI etc. this > parameter has to be added but I would prefere to ALWAYS > use this new parameter instead of sometimes using maddr. Unfortunately, this is not backwards compatible, whereas what I proposed -- if one is generous -- was completely backwards compatible. (Technically, I think it conflicts with the bis drafts, but that is all?) To be honest, I've been slightly disappointed with the lack of response to my original suggestion; inflamatory or otherwise. I would have thought it was controversial enough to merit a medium-sized fire extinguisher at the very least. &:) I think (please do correct if I wrong) that my solution potentially addressed all the problems in and around this thread; it even left the way open for state to be stored in the Request-URIs (I would prefer to see the State header used for this, but obviously there is then an issue of what to do if a UA don't support it). It'd be nice if we could try and get this nailed down once and for all[0] before the Bake-Off, whichever hammer we use. That way, we can all offer up our bleeding-edge I-knocked-it-up-during-the-flight-over-here implementations there and then, and prove it works (or doesn't, as the case may be). I'm sure a "simple" scenario involving a single spiral would suffice... Cheers, - Jo. [0] Until we realise the next bug, of course. &:) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 08:59: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 IAA14725 for ; Mon, 13 Nov 2000 08:59:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3216944338; Mon, 13 Nov 2000 07:59:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 69C1C44336 for ; Mon, 13 Nov 2000 07:58:38 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id FAA17478; Mon, 13 Nov 2000 05:52:56 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SIP] Multiple Aliases From: David Shrader To: Jo Hornsby , zeeshan razzaque , Message-ID: In-Reply-To: <004b01c04d63$2f9726f0$4e34c3c1@ubiquity.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 08:48:02 -0500 Content-Transfer-Encoding: 7bit You could also register with multiple service providers. ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com > From: "Jo Hornsby" > Date: Mon, 13 Nov 2000 11:16:36 -0000 > To: "zeeshan razzaque" , > Subject: RE: [SIP] Multiple Aliases > >> Hi, Can my UA be registered with multiple Aliases? >> (analogous to having a single mailbox for different >> email addresses) > > Very much so (the only thing preventing this would be > a lack of Service Providers/Registrars willing to let > you do this). > > > - 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 Nov 13 09:04: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 JAA16930 for ; Mon, 13 Nov 2000 09:04:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DD1EA4435D; Mon, 13 Nov 2000 08:04:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 00FD244338 for ; Mon, 13 Nov 2000 08:03:20 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id FAA20149; Mon, 13 Nov 2000 05:58:46 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SIP] SIP ringback tone From: David Shrader To: "Fairlie-Cuninghame, Robert" Cc: SIP List Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 08:53:57 -0500 Content-Transfer-Encoding: 7bit Robert, I don't agree that 183 with SDP should only be a call progress message. It is a perfectly reasonable usage to support ringback. This is especially necessary when interworking with the PSTN where ringback is delivered inband. If you implement a system that works with the PSTN, I think we shouldn't require it to support two modes of operation. It seems reasonable that the use of 183 masks whether I'm going to the PSTN or another SIP endpoint identified by a telephone number and allows the person or network being called to provide whatever inband indication it chooses. David ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com > From: "Fairlie-Cuninghame, Robert" > Date: Mon, 13 Nov 2000 03:33:35 -0800 > To: "'Henry Sinnreich'" > Cc: "'sip@lists.bell-labs.com'" > Subject: RE: [SIP] SIP ringback tone > > Henry, > > Innovative ringback greetings definitely seem like a case for an early media > to me. > > As an aside, many people still seem to erroroneously think that 183 Session > Progress should be used for early-media ring-back. 180 Ringing with SDP > should be used for ringback purposes, 183 with SDP should only be used for > call progress messages (ie, not alerting the user). I still think this needs > to be made clearer in the spec! > > Cheers, > > Robert. > > -- My opinions are my own. I tried selling them once but everybody > seems to already have one. -- > >> -----Original Message----- >> From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] >> Sent: Monday, November 13, 2000 6:18 AM >> To: adam.roach@ericsson.com; IETF SIP (E-mail) >> Subject: [SIP] SIP ringback tone >> >> >> The draft on "Ringback tones in SIP-Based Telephony" shows >> impressive work >> on preserving legacy country specific ring back tones. I >> wonder if we would >> not be better of by adding a >> >> SIP Ringback Tone >> ================= >> >> With some optional fields where service providers could add innovative >> greetings. >> >> Henry >> >> Henry Sinnreich >> WorldCom >> 400 International Parkway, >> Richardson, Texas, 75081 >> >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 13 09:14:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21260 for ; Mon, 13 Nov 2000 09:14:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB0B144366; Mon, 13 Nov 2000 08:14:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 344B84435D for ; Mon, 13 Nov 2000 08:13:43 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA02479; Mon, 13 Nov 2000 09:15:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YW7A>; Mon, 13 Nov 2000 09:11:59 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] failure of 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: Mon, 13 Nov 2000 09:11:58 -0500 > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Wednesday, November 08, 2000 6:02 AM > To: Jonathan Rosenberg > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] failure of proxy > > > > > Jonathan Rosenberg wrote: > > > > > For things to work consistently, the SRV lookup process > should be based on > > the pseudo-random number generator I suggested in a > previous thread; thats > > the one based on a hash of the Call-ID, amongst other > things. This gives us > > consistent operation for SRV records in general. > > As I replied in a previous thread (with a bad example) this > hash based method > gives us nothing in general it only works if you locally > cache DNS for the life > time of a transaction, for each transaction (hence truly > stateless proxy servers > do not work ;^) ). The reason for this is simple for the > hash method to work > the result from the DNS query MUST be identical even in > ordering of the RRs each > time. OK, so my proposal is that a UA or proxy that does a DNS query should order entries of equal priority and preference using some sorting rule, alphabetical or whatever. We really need for this to work somehow. As an example of why this may not happen I'll admit my > short comings, the > first time I implemented SRV lookups I was lazy I found the > lowest priority RRs > and picked the first one. If I was writing a DNS server I may > expect other > people to do this, and in a more thorough moment may decide > to shuffle the > results my server returned for SRV records (this wouldn't > provide the same level > of load balancing but could help). > > Also it's possible the zone file might have changed. In that case, I think it is reasonable that requests may go to different places. -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 Nov 13 09:18: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 JAA22993 for ; Mon, 13 Nov 2000 09:18:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A88E44366; Mon, 13 Nov 2000 08:18:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 73EC04435D for ; Mon, 13 Nov 2000 08:17:33 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA02503; Mon, 13 Nov 2000 09:19:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YW7G>; Mon, 13 Nov 2000 09:15:48 -0500 Message-ID: From: Jonathan Rosenberg To: "'vkg@lucent.com'" , Juha Heinanen Cc: sip@lists.bell-labs.com Subject: RE: [SIP] bye and record route MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 09:15:47 -0500 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Thursday, November 09, 2000 2:25 PM > To: Juha Heinanen > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] bye and record route > > > Juha Heinanen wrote: > > > > section 4.2.4 bye says: > > > > If the INVITE request contained a Contact header, the callee SHOULD > > send a BYE request to that address rather than the From address. > > > > if the invite had record route header, shouldn't the bye request be > > send to its maddr instead? > > Right. When a UAC wants to send the request to it's next hop AND a > Route list has been constructed, it'll examine the topmost Route and > follow the rules listed in Section 1.4.2, "Locating a SIP Server" to > figure out the destination. Step 1 in that section says, "If maddr > parameter exists, it becomes the /destination address/ used ..." The text in 4.2.4 as it reads now is incorrect. The BYE should be sent using the regular routing mechanisms. THe text would seem to imply that you would ignore record-routes for BYE, which is wrong, as Vijay has correctly pointed out. One of the cleanup items in my list is to consolidate all this text on next hop computations into one place. Right now its all over the place and not always consistent. -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 Nov 13 10: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 KAA28330 for ; Mon, 13 Nov 2000 10:40:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A4BED44338; Mon, 13 Nov 2000 09:40:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id D3F6444336 for ; Mon, 13 Nov 2000 09:39:09 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA27936 for ; Mon, 13 Nov 2000 10:38:59 -0500 (EST) Message-ID: <3A100B13.264E75CF@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Nanonit: no references in abstracts Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 13 Nov 2000 10:38:59 -0500 Content-Transfer-Encoding: 7bit Authors of Internet drafts: Please do not include numeric citations, such as "SIP [1] is ..." in abstracts. They produce dangling references in I-D announcements and various other places. The I-D/RFC editor doesn't like those, either... Henning (maintainer of the rfc.bib and i-d.bib BibTeX files and various lists of SIP abstracts) -- 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 Nov 13 11:03:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06575 for ; Mon, 13 Nov 2000 11:03:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 304AC44371; Mon, 13 Nov 2000 10:03:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web1401.mail.yahoo.com (web1401.mail.yahoo.com [128.11.23.165]) by lists.bell-labs.com (Postfix) with SMTP id BBE0A44336 for ; Mon, 13 Nov 2000 04:38:58 -0500 (EST) Received: (qmail 22865 invoked by uid 60001); 13 Nov 2000 10:38:51 -0000 Message-ID: <20001113103851.22864.qmail@web1401.mail.yahoo.com> Received: from [192.245.102.12] by web1401.mail.yahoo.com; Mon, 13 Nov 2000 02:38:51 PST From: Niranjan Dhanakoti To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] SIP Clarification Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 02:38:51 -0800 (PST) Hi, My name is Niranjan and am working on SIP Stack for our Call Agent\MGC. I would like to know if there are any HTTP Parser tools available for SIP ? Please Clarify... With Regards, Niranjan Dahanakoti Axes Technologies Pvt Ltd. __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 11:04: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 LAA07340 for ; Mon, 13 Nov 2000 11:04:50 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6192844376; Mon, 13 Nov 2000 10:03:18 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id C6FF74435D for ; Mon, 13 Nov 2000 05:41:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06142; Mon, 13 Nov 2000 06:40:56 -0500 (EST) Message-Id: <200011131140.GAA06142@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-privacy-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 06:40:56 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Extensions for Caller Identity and Privacy Author(s) : W. Marshall et al. Filename : draft-ietf-sip-privacy-00.txt Pages : 16 Date : 10-Nov-00 This document describes two extensions to the Session Initiation Protocol (SIP) [4]. The extensions allow callers and callees to maintain their privacy in an environment where one or more proxies serve as intermediaries which can provide the identity of the parties either directly or indirectly. The extensions allow the parties to be identified either by name or by type, the latter of which can be used to identify some group of callers and callees. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-privacy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-privacy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001110140255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-privacy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-privacy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001110140255.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 11: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 LAA08692 for ; Mon, 13 Nov 2000 11:08:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C458A4437B; Mon, 13 Nov 2000 10:03:29 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id CDC044435D for ; Mon, 13 Nov 2000 05:41:13 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06272; Mon, 13 Nov 2000 06:41:07 -0500 (EST) Message-Id: <200011131141.GAA06272@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-manyfolks-resource-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 06:41:06 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Integration of Resource Management and SIP Author(s) : B. Marshall et al. Filename : draft-ietf-sip-manyfolks-resource-00.txt Pages : 25 Date : 10-Nov-00 This document discusses how network QoS and security establishment can be made a precondition to sessions initiated by the Session Initiation Protocol (SIP), and described by SDP. These preconditions require that the participant reserve network resources (or establish a secure media channel) before continuing with the session. We do not define new QoS reservation or security mechanisms; these pre- conditions simply require a participant to use existing resource reservation and security mechanisms before beginning the session. This results in a multi-phase call-setup mechanism, with the resource management protocol interleaved between two phases of call signaling. The objective of such a mechanism is to enable deployment of robust IP Telephony services, by ensuring that resources are made available before the phone rings and the participants of the call are 'invited' to participate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-manyfolks-resource-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-manyfolks-resource-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001110140320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-manyfolks-resource-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-manyfolks-resource-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001110140320.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 11:34: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 LAA18448 for ; Mon, 13 Nov 2000 11:34:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B88B44338; Mon, 13 Nov 2000 10:34:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 985C844336 for ; Mon, 13 Nov 2000 10:33:56 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id IAA29316 for ; Mon, 13 Nov 2000 08:29:25 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 From: David Shrader To: SIP List Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [SIP] Registration, Routing, and Record-Route Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 11:24:38 -0500 Content-Transfer-Encoding: 7bit I have a scenario that I am trying to solve using SIP. The pieces don't quite seem to come together for me. Do you have any thoughts? Given the following constraints (lets assume for this scenario): 1. A sip user agent must access a service provider network via a specific proxy that is to be used for the life of the particular registration. (After re-boot or network condition, a different proxy may be used to register.) 2. The service provider will route all calls to that user agent via the specific proxy also for the life of the particular registration. 3. The SIP UA registers its current location with the network domain server via the proxy. 4. The network domain server receiving an INVITE for the user, determines the users current location and needs to now route all calls to the current location via the proxy. Is there a SIP mechanism associated with the registration that can indicate this? I think that the REGISTER message in step 3 has a Request-URI of the network domain server and is routed to the IP address of the proxy. The proxy would then look at the Request-URI and forward the request on to the network domain server. One thought I had was that a Record-Route added by the proxy would establish a route that would be taken for all of subsequent registration requests on that registration "call leg". This, however, would not necessarily apply to subsequent INVITEs for new calls. Anybody have any thoughts on this problem? David ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 12:04: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 MAA01304 for ; Mon, 13 Nov 2000 12:04:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF23344338; Mon, 13 Nov 2000 11:04:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id B027344336 for ; Mon, 13 Nov 2000 11:03:51 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 09:04:43 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP ringback tone 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, 13 Nov 2000 09:04:42 -0800 The way the spec is written at the moment (see Section 7.1 - it changed recently), a UAC should be able to accept any 1xx response (other than 100) with SDP as indicating early media. eg 183, 182, 181 or 180. Obviously they must have different meanings or there is no reason to have the different response codes (COMET aside). Both the expired 183 draft (explicitly) and the bis-02 draft (inferred) say that 183 indicates call progress events _other_ than user alerting (eg "queued message", "please wait, verifying" or "enter pin number" voice messages) --- yet the mechanism is the same for 180 and 183. [I just think it should be made clearer in the 183 description.] I don't understand your point about requiring support for two mechanisms and that it "masks whether I'm going to the PSTN or another SIP endpoint identified by a telephone number". How so? And more importantly, why is this necessary ? In fact I would say the opposite is true. A SIP client that is not PSTN centric and doesn't bother with early media playback should not have to know that 183 is actually ringback on a PSTN SIP client. The client should simply know that a received 180 indicates user alerting, 182 is queued and 183 is some other call progress event. Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: David Shrader [mailto:dshrader@master-consultant.com] > Sent: Monday, November 13, 2000 9:54 PM > To: Fairlie-Cuninghame, Robert > Cc: SIP List > Subject: Re: [SIP] SIP ringback tone > > > Robert, > > I don't agree that 183 with SDP should only be a call > progress message. It > is a perfectly reasonable usage to support ringback. This is > especially > necessary when interworking with the PSTN where ringback is delivered > inband. If you implement a system that works with the PSTN, I think we > shouldn't require it to support two modes of operation. It > seems reasonable > that the use of 183 masks whether I'm going to the PSTN or another SIP > endpoint identified by a telephone number and allows the > person or network > being called to provide whatever inband indication it chooses. > > David > > ---------------------------- > David Shrader > Master Consultant, Inc. > dshrader@master-consultant.com > http://www.EyeForTheFuture.com > > > From: "Fairlie-Cuninghame, Robert" > > Date: Mon, 13 Nov 2000 03:33:35 -0800 > > To: "'Henry Sinnreich'" > > Cc: "'sip@lists.bell-labs.com'" > > Subject: RE: [SIP] SIP ringback tone > > > > Henry, > > > > Innovative ringback greetings definitely seem like a case > for an early media > > to me. > > > > As an aside, many people still seem to erroroneously think > that 183 Session > > Progress should be used for early-media ring-back. 180 > Ringing with SDP > > should be used for ringback purposes, 183 with SDP should > only be used for > > call progress messages (ie, not alerting the user). I still > think this needs > > to be made clearer in the spec! > > > > Cheers, > > > > Robert. > > > > -- My opinions are my own. I tried selling them once but everybody > > seems to already have one. -- > > > >> -----Original Message----- > >> From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > >> Sent: Monday, November 13, 2000 6:18 AM > >> To: adam.roach@ericsson.com; IETF SIP (E-mail) > >> Subject: [SIP] SIP ringback tone > >> > >> > >> The draft on "Ringback tones in SIP-Based Telephony" shows > >> impressive work > >> on preserving legacy country specific ring back tones. I > >> wonder if we would > >> not be better of by adding a > >> > >> SIP Ringback Tone > >> ================= > >> > >> With some optional fields where service providers could > add innovative > >> greetings. > >> > >> Henry > >> > >> Henry Sinnreich > >> WorldCom > >> 400 International Parkway, > >> Richardson, Texas, 75081 > >> > >> > >> > >> _______________________________________________ > >> SIP mailing list > >> SIP@lists.bell-labs.com > >> http://lists.bell-labs.com/mailman/listinfo/sip > >> > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > 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 Nov 13 12:13: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 MAA04357 for ; Mon, 13 Nov 2000 12:13:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9510744362; Mon, 13 Nov 2000 11:13:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 6B99744338 for ; Mon, 13 Nov 2000 11:12:56 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA29793; Mon, 13 Nov 2000 11:12:48 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eADHAZk12996; Mon, 13 Nov 2000 11:10:35 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA20667; Mon, 13 Nov 2000 11:12:45 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA25830; Mon, 13 Nov 2000 11:12:55 -0600 (CST) Message-Id: <200011131712.LAA25830@b04a24.exu.ericsson.se> Subject: Re: [SIP] Ringback draft To: hgs@cs.columbia.edu (Henning G. Schulzrinne) Cc: sip@lists.bell-labs.com In-Reply-To: <3A0C7BA1.3B0BC3D8@cs.columbia.edu> from "Henning G. Schulzrinne" at Nov 10, 2000 05:50:09 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 11:12:54 -0600 (CST) Content-Transfer-Encoding: 7bit Henning G. Schulzrinne writes: >Note also that you could use the Alert-Info for the >same purpose, by providing an external (cached) reference to whatever >national tones you'd like the caller to hear. I believe this to be the opposite of "Alert-Info." My understanding is that "Alert-Info" indicates content to be rendered to the callED party. My draft addresses content to be rendered to the callING party. Please correct me if I'm mistaken. -- 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 Nov 13 12:30:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10072 for ; Mon, 13 Nov 2000 12:30:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2151E44374; Mon, 13 Nov 2000 11:30:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 4511644362 for ; Mon, 13 Nov 2000 11:28:59 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA05703; Mon, 13 Nov 2000 12:28:47 -0500 (EST) Message-ID: <3A1024CF.EEB094D7@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Ringback draft References: <200011131712.LAA25830@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 12:28:47 -0500 Content-Transfer-Encoding: 7bit "Adam B. Roach" wrote: > > Henning G. Schulzrinne writes: > >Note also that you could use the Alert-Info for the > >same purpose, by providing an external (cached) reference to whatever > >national tones you'd like the caller to hear. > > I believe this to be the opposite of "Alert-Info." > > My understanding is that "Alert-Info" indicates content to be rendered > to the callED party. My draft addresses content to be rendered to the > callING party. > > Please correct me if I'm mistaken. You're right; as currently defined. What I meant and should have spelled out is that it may make sense (if this functionality makes sense, which I'm less than convinced...) to also define Alert-Info as a response header, not just a request header. -- 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 Nov 13 12:58: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 MAA18656 for ; Mon, 13 Nov 2000 12:58:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1700144338; Mon, 13 Nov 2000 11:58:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id A735E44336 for ; Mon, 13 Nov 2000 11:57:39 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 13 Nov 2000 17:57:33 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id SAA18509; Mon, 13 Nov 2000 18:56:05 +0100 (BST) Message-ID: <3A102B34.3F1FEEBC@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sip List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] new torture tests Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 13 Nov 2000 17:56:04 +0000 Content-Transfer-Encoding: 7bit The following are 15 new proposed torture test messages based on the bis draft. None of them should cause good implementations to crash. Recommended responses to the illegal messages are given where needed. I would greatly appreciate any additions/corrections to be made quickly so we can try to get these folded into a new release of the call flows draft before the next bakeoff. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net 1) Illegal enclosing of Request-URI in "<>" Server should respond with 400 + Appropriate Reason Phrase. INVITE SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 1@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 2) Illegal LWS in elements of Request-URI Server should respond with 400 + Appropriate Reason Phrase. INVITE sip:user@company.com; transport=udp SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 2@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 3) Illegal >1 SP between elements of Request URI Server should respond with 400 + Appropriate Reason Phrase. INVITE sip:user@company.com SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 3@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 4) Legal SIP URL in Request URI with escaped characters and parameter. INVITE sip%3Auser%40company.com;other-param=summit SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 4@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 5) Illegal use of escaped header in Request-URI Proxies should strip off the escaped header before proxying on. INVITE sip:user@company.com?Route=%3Csip:sip.example.com%3E SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 5@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 6) Not understood URI in Req-URI but a SIP URL in To. Server should respond 400 + Appropriate Reason Phrase INVITE name:user SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 6@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 7) Legal no LWS between display name and < OPTIONS sip:user@company.com SIP/2.0 To: sip:user@company.com From: "caller" Call-ID: 1234abcd@10.0.0.1 CSeq: 1 OPTIONS Via: SIP/2.0/UDP 135.180.130.133 8) Legal extra LWS between display name and < OPTIONS sip:user@company.com SIP/2.0 To: sip:user@company.com From: "caller" Call-ID: 1234abcd@10.0.0.1 CSeq: 2 OPTIONS Via: SIP/2.0/UDP 135.180.130.133 9) Illegal Non GMT time zone in SIP Date A liberal server should correct this. INVITE sip:user@company.com SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 7@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Expires: Fri, 01 Jan 2010 16:00:00 EST Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 10) Legal message with passed Exipres date. A Server should respond 408 Request Timeout. INVITE sip:user@company.com SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 8@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Expires: Thu, 01 Dec 1994 16:00:00 GMT Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 11) Legal message with zero max forwards Proxies should return 483 Too Many Hops, a UAS responds as for OPTIONS. INVITE sip:user@company.com SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 9@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Max-Forwards: 0 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 12) Legal REGISTER with SIP URL containing escaped Route header in Contact. REGISTER sip:company.com SIP/2.0 To: sip:user@company.com From: sip:user@company.com Contact: sip:user@host.company.com Call-ID: k345asrl3fdbv@10.0.0.1 CSeq: 1 REGISTER Via: SIP/2.0/UDP 135.180.130.133 Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E 13) Legal but long, includes Token for Call-ID. INVITE sip:user@company.com SIP/2.0 To: "I have a user name of extreme proportion" From: sip:caller@university.edu Call-ID: kl24ahsd546folnyt2vbak9sad98u23naodiunzds09a3bqw0sdfbsk34poouymnae0043nsed09mfkvc74bd0cuwnms05dknw87hjpobd76f CSeq: 1 INVITE My-State: sldkjflzdsfaret0803adgaasd0afds0asdaasd Via: SIP/2.0/UDP sip33.example.com Via: SIP/2.0/UDP sip32.example.com Via: SIP/2.0/UDP sip31.example.com Via: SIP/2.0/UDP sip30.example.com Via: SIP/2.0/UDP sip29.example.com Via: SIP/2.0/UDP sip28.example.com Via: SIP/2.0/UDP sip27.example.com Via: SIP/2.0/UDP sip26.example.com Via: SIP/2.0/UDP sip25.example.com Via: SIP/2.0/UDP sip24.example.com Via: SIP/2.0/UDP sip23.example.com Via: SIP/2.0/UDP sip22.example.com Via: SIP/2.0/UDP sip21.example.com Via: SIP/2.0/UDP sip20.example.com Via: SIP/2.0/UDP sip19.example.com Via: SIP/2.0/UDP sip18.example.com Via: SIP/2.0/UDP sip17.example.com Via: SIP/2.0/UDP sip16.example.com Via: SIP/2.0/UDP sip15.example.com Via: SIP/2.0/UDP sip14.example.com Via: SIP/2.0/UDP sip13.example.com Via: SIP/2.0/UDP sip12.example.com Via: SIP/2.0/UDP sip11.example.com Via: SIP/2.0/UDP sip10.example.com Via: SIP/2.0/UDP sip9.example.com Via: SIP/2.0/UDP sip8.example.com Via: SIP/2.0/UDP sip7.example.com Via: SIP/2.0/UDP sip6.example.com Via: SIP/2.0/UDP sip5.example.com Via: SIP/2.0/UDP sip4.example.com Via: SIP/2.0/UDP sip3.example.com Via: SIP/2.0/UDP sip2.example.com Via: SIP/2.0/UDP sip1.example.com Via: SIP/2.0/UDP host.example.com;received=135.180.130.133;branch=C1C3344E2710000000E299E568E7potato10potato0potato0 Content-Type: application/sdp v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 14) Illegal, badly mangled message with mutliple To, From, Call-ID and CSeq headers. Server should respond 400 + Appropriate Reason Phrase OPTIONS sip:135.180.130.133 SIP/2.0 Via: SIP/2.0/UDP company.com:5604 From: sip:iuser@company.com To: sip:user@135.180.130.133 Call-ID: 1804928587@company.com CSeq: 1 OPTIONS Expires: 0 0l@company.com To: sip:user@135.180.130.133 Call-ID: 1804928587@company.com CSeq: 1 OPTIONS Contact: sip:host.company.com Expires: 0xpires: 0sip:host.company.com Expires: 0 Contact: sip:host.company.com 15) Legal message with an unusual amount of SDP attributes. INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 56 INVITE Content-Type: application/sdp Content-Length: 320 v=0 o=faxgw1 2890844527 2890844527 IN IP4 iftgw.there.com s=Session SDP c=IN IP4 iftmg.there.com t=0 0 m=image 49172 udptl t38 a=T38FaxVersion:0 a=T38maxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:260 a=T38FaxUdpEC:t38UDPRedundancy _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 13:11:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22308 for ; Mon, 13 Nov 2000 13:11:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A11D244374; Mon, 13 Nov 2000 12:11:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from guard.kazmier.com (h00104bedbbc7.ne.mediaone.net [24.168.162.28]) by lists.bell-labs.com (Postfix) with SMTP id 2F04C44336 for ; Mon, 13 Nov 2000 10:33:29 -0500 (EST) Received: (qmail 24067 invoked from network); 13 Nov 2000 16:33:22 -0000 Received: from view.kazmier.com (172.25.1.51) by guard.kazmier.com with SMTP; 13 Nov 2000 16:33:22 -0000 Received: (qmail 23742 invoked by uid 1000); 13 Nov 2000 16:33:21 -0000 From: "Pete Kazmier" To: sip@lists.bell-labs.com Message-ID: <20001113113321.C17325@kazmier.com> Mail-Followup-To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Subject: [SIP] Gateway and Redirected Number 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: Mon, 13 Nov 2000 11:33:21 -0500 If a PSTN originated call is redirected to a gateway, how would, for example, a Q.931 redirected number or SS7 RDN/OCN be mapped into a SIP INVITE message? I've been looking through various drafts to determine the appropriate action but I can't seem to find the right one. Could somone point me in the right direction? Thanks. -- Peter Kazmier http://www.kazmier.com PGP Fingerprint 4FE7 8DA3 D0B5 9CAA 69DC 7243 1855 BC2E 4B43 5654 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 13:31: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 NAA28089 for ; Mon, 13 Nov 2000 13:31:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5385D44338; Mon, 13 Nov 2000 12:31:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by lists.bell-labs.com (Postfix) with ESMTP id CE84644336 for ; Mon, 13 Nov 2000 12:30:46 -0500 (EST) Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA26608; Mon, 13 Nov 2000 13:28:45 -0500 (EST) Received: from bgracely-pc (rtp-pv54-dhcp-148.cisco.com [161.44.54.148]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABM03783; Mon, 13 Nov 2000 13:30:31 -0500 (EST) Message-Id: <4.2.0.58.20001113132647.00a53600@dingdong.cisco.com> X-Sender: bgracely@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 To: "Pete Kazmier" , sip@lists.bell-labs.com From: Brian Gracely Subject: Re: [SIP] Gateway and Redirected Number Question In-Reply-To: <20001113113321.C17325@kazmier.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 13:27:24 -0500 http://search.ietf.org/internet-drafts/draft-levy-sip-diversion-00.txt At 11:33 AM 11/13/2000 -0500, Pete Kazmier wrote: >If a PSTN originated call is redirected to a gateway, how would, for >example, a Q.931 redirected number or SS7 RDN/OCN be mapped into a SIP >INVITE message? > >I've been looking through various drafts to determine the appropriate >action but I can't seem to find the right one. Could somone point me >in the right direction? > >Thanks. > >-- >Peter Kazmier http://www.kazmier.com >PGP Fingerprint 4FE7 8DA3 D0B5 9CAA 69DC 7243 1855 BC2E 4B43 5654 > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >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 Nov 13 14:17:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13581 for ; Mon, 13 Nov 2000 14:17:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BDE5E44338; Mon, 13 Nov 2000 13:17:07 -0500 (EST) 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 0512E44336 for ; Mon, 13 Nov 2000 13:16:55 -0500 (EST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id TAA13817 for ; Mon, 13 Nov 2000 19:18:04 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 13 Nov 2000 19:16:46 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 11:16:45 -0800 Message-ID: From: "Agarwal, Aseem" To: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-manyfolks-resource-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 10:26:18 -0800 Hi, Is this document different from draft-manyfolks-sip-resource-01.txt ?? If not, should n't this document have a higher version number ? Also, does this draft obsolete "Establishing QOS and Security Preconditions for SDP Sessions", draft-ietf-mmusic-sdp-qos-00.txt ?? thanks, aseem -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, November 13, 2000 3:41 AM Cc: sip@lists.bell-labs.com Subject: [SIP] I-D ACTION:draft-ietf-sip-manyfolks-resource-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Integration of Resource Management and SIP Author(s) : B. Marshall et al. Filename : draft-ietf-sip-manyfolks-resource-00.txt Pages : 25 Date : 10-Nov-00 This document discusses how network QoS and security establishment can be made a precondition to sessions initiated by the Session Initiation Protocol (SIP), and described by SDP. These preconditions require that the participant reserve network resources (or establish a secure media channel) before continuing with the session. We do not define new QoS reservation or security mechanisms; these pre- conditions simply require a participant to use existing resource reservation and security mechanisms before beginning the session. This results in a multi-phase call-setup mechanism, with the resource management protocol interleaved between two phases of call signaling. The objective of such a mechanism is to enable deployment of robust IP Telephony services, by ensuring that resources are made available before the phone rings and the participants of the call are 'invited' to participate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-manyfolks-resource-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-manyfolks-resource-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 14:33: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 OAA19260 for ; Mon, 13 Nov 2000 14:33:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D33D244383; Mon, 13 Nov 2000 13:33:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 716CF44338 for ; Mon, 13 Nov 2000 13:32:30 -0500 (EST) 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 OAA06345; Mon, 13 Nov 2000 14:34:28 -0500 (EST) From: "Robert Sparks" To: "Adam B. Roach" Cc: Subject: RE: [SIP] Possible REFER problem? 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: <200011090015.SAA15146@b04a24.exu.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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, 13 Nov 2000 13:30:33 -0600 Content-Transfer-Encoding: 7bit I had to rethink this whole conversation to respond, and as part of the process captured the following notes. Hopefully, they'll be a helpful summary: The scenario that started this discussion consisted of A calling B, A puts B on hold, A calls C, A then wants to transfer B to C and try to ensure that the same B gets the same C-endpoint that A was talking to. The question was whether the Refer-To header in the REFER message that A sends to B should contain the URL that A used to reach C in the first place, or the URL that C returned in the 200 OK to A's INVITE. The Contact that C provided to A is only guaranteed to make sense in the context of A's session with C. For example, the hostname may be in a private namespace in a company's LAN. A and B would both fail if they did a DNS lookup on it, but the last proxy on the Route before that contact would have no problems with it. Even if C gave A a contact that A could resolve, there is no guarantee that C will honor that contact outside the call leg that A and C have set up. Jonathan's suggested method is to place the contact that C gave to A in the Accept-Contact header to increase the probability (not ensure) that B reaches the same C-endpoint that A did. Given all that, and the likelyhood that for many (if not most) instances, the contact provided in the Contact URL _is_ routable, what problems exist with taking the following approach? 1) REFER B directly to the contact that C provided to A. 2) If it fails, REFER B to C's well known URL with an Accept-Contact header containing the contact that C provided to A. RjS > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Adam B. Roach > Sent: Wednesday, November 08, 2000 6:15 PM > To: Eric Tremblay > Cc: 'Jonathan Rosenberg'; 'Cliff.Harris@nokia.com'; Eric Tremblay; > 'sip@lists.bell-labs.com' > Subject: Re: [SIP] Possible REFER problem? > > > Eric Tremblay writes: > >I'm reviving and old thread ;) > > > >If you remember, the problem was when doing call transfer with > consultation > >with the REFER request, how can we make sure that the INVITE > request (from > >the Transferee to the Transfer Target) is going to reach the exact same > >User-Agent as the one that was consulted by the Transferor. > > > >The solution was to use the header "Accept-Contact" and specify > the contact > >of the transfer target. > > > > At the risk of sounding daft, I don't see why using the "Contact:" > header as the new "INVITE" URI is considered Evil in this case. > > When explaining the difference between, say, the "From:" (or "To:") > field and the "Contact:" field, I generally think of "From:"/"To:" as > being the persistent URI for contacting the appropriate resource in > an abstract sense (by resource, I mean "Adam Roach" or "helpdesk staffer" > or "sales representative"), while the "Contact:" URI indicates "where to > get to me (as a particular instance of that resource) on this particular > device at this particular moment." > > Obviously, the most useful application of this latter piece of information > is routing of subsequent messages for a particular call -- but I don't > see why it absolutely MUST be the only use for this information. > > For the "Contact" information to be useful in any way, it needs to be > something that can be routed when used as a Request-URI; it wouldn't > work for "BYE" messages otherwise, right? > > So, if the transferee were passed this information to be used as > the Request-URI, there should be no discernable problems with the > INVITE (or other appropriate method) arriving at the partcular > instance of the desired resource on a particular device. > > Since no one else has raised this point, I'm going to assume that > I'm too blind to see the elephant in the room. So, could someone > explain *why* using a Contact URI in this manner would be inappropriate > behavior? > > -- > Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. > Arapaho, MS L-04 > adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX > 75081 USA > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 15:12: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 PAA01196 for ; Mon, 13 Nov 2000 15:12:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAE8044398; Mon, 13 Nov 2000 14:12:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 9423144397 for ; Mon, 13 Nov 2000 14:11:41 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 13 Nov 2000 14:11:21 -0600 (CST) From: Billy Biggs To: Robert Sparks Cc: "Adam B. Roach" , sip@lists.bell-labs.com Subject: Re: [SIP] Possible REFER problem? Message-ID: <20001113141121.A26636@div8.net> References: <200011090015.SAA15146@b04a24.exu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from rsparks@dynamicsoft.com on Mon, Nov 13, 2000 at 01:30:33PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 13 Nov 2000 14:11:21 -0600 Robert Sparks (rsparks@dynamicsoft.com): > [...] > > The scenario that started this discussion consisted of A calling B, A > puts B on hold, A calls C, A then wants to transfer B to C and try to > ensure that the same B gets the same C-endpoint that A was talking to. > > The question was whether the Refer-To header in the REFER message that > A sends to B should contain the URL that A used to reach C in the > first place, or the URL that C returned in the 200 OK to A's INVITE. C may have called A, in which case the well known URL is unknown. You can't use the From here either since it is outside of the scope. > The Contact that C provided to A is only guaranteed to make > sense in the context of A's session with C. [...] I disagree with this. The contact that C provided has to be available at least for new calls within the local namespace, and if not, then whatever translator in the middle (outbound proxy, transparent masquerade host or whatever) has to know to check the Refer-To header and mangle it also. Otherwise this gets too complicated. > Jonathan's suggested method is to place the contact that C gave to A > in the Accept-Contact header to increase the probability (not ensure) > that B reaches the same C-endpoint that A did. And put that as a header parameter in the URL given in the Refer-To header? This seems like a big hack, especially since the well known URL may not be known. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 15: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 PAA09485 for ; Mon, 13 Nov 2000 15:34:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F6A744339; Mon, 13 Nov 2000 14:34:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4B5B144336 for ; Mon, 13 Nov 2000 14:33:51 -0500 (EST) 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 PAA07230; Mon, 13 Nov 2000 15:35:57 -0500 (EST) From: "Robert Sparks" To: "Billy Biggs" Cc: "Adam B. Roach" , Subject: RE: [SIP] Possible REFER problem? 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: <20001113141121.A26636@div8.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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, 13 Nov 2000 14:32:01 -0600 Content-Transfer-Encoding: 7bit > > The scenario that started this discussion consisted of A calling B, A > > puts B on hold, A calls C, A then wants to transfer B to C and try to > > ensure that the same B gets the same C-endpoint that A was talking to. > > > > The question was whether the Refer-To header in the REFER message that > > A sends to B should contain the URL that A used to reach C in the > > first place, or the URL that C returned in the 200 OK to A's INVITE. > > C may have called A, in which case the well known URL is unknown. You > can't use the From here either since it is outside of the scope. Interesting thought. Really unusual preconditions though. "Let me transfer you to this other person that just called me". In that case, the contact they've provided is the best you've got unless you can get better information through another channel. > > > The Contact that C provided to A is only guaranteed to make > > sense in the context of A's session with C. [...] > > I disagree with this. The contact that C provided has to be available > at least for new calls within the local namespace, and if not, then > whatever translator in the middle (outbound proxy, transparent > masquerade host or whatever) has to know to check the Refer-To header > and mangle it also. > > Otherwise this gets too complicated. I'm not sure what/who you're disagreeing with? The contact that C provides has only to be valid for subsequent requests in that call-leg. (I can't imagine anyone actually implementing it that way, but afaict, that's all the spec requires). > > > Jonathan's suggested method is to place the contact that C gave to A > > in the Accept-Contact header to increase the probability (not ensure) > > that B reaches the same C-endpoint that A did. > > And put that as a header parameter in the URL given in the Refer-To > header? This seems like a big hack, especially since the well known URL > may not be known. > You didn't comment on the hybrid approach at the end of the message. I think it addresses the case you are wanting to solve (as the primary usage even). 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 Nov 13 16:28: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 QAA29314 for ; Mon, 13 Nov 2000 16:28:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6BD0244339; Mon, 13 Nov 2000 15:28:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 4995D44336 for ; Mon, 13 Nov 2000 15:27:16 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 13 Nov 2000 15:26:56 -0600 (CST) From: Billy Biggs To: Robert Sparks Cc: Billy Biggs , "Adam B. Roach" , sip@lists.bell-labs.com Subject: Re: [SIP] Possible REFER problem? Message-ID: <20001113152656.A26717@div8.net> References: <20001113141121.A26636@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from rsparks@dynamicsoft.com on Mon, Nov 13, 2000 at 02:32:01PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 13 Nov 2000 15:26:56 -0600 Robert Sparks (rsparks@dynamicsoft.com): > > > The scenario that started this discussion consisted of A calling > > > B, A puts B on hold, A calls C, A then wants to transfer B to C > > > and try to ensure that the same B gets the same C-endpoint that A > > > was talking to. > > > > > > The question was whether the Refer-To header in the REFER message > > > that A sends to B should contain the URL that A used to reach C in > > > the first place, or the URL that C returned in the 200 OK to A's > > > INVITE. > > > > C may have called A, in which case the well known URL is unknown. > > You can't use the From here either since it is outside of the > > scope. > > Interesting thought. Really unusual preconditions though. "Let me > transfer you to this other person that just called me". In that case, > the contact they've provided is the best you've got unless you can get > better information through another channel. It's not unusual when you consider the general problem: how to excuse yourself from a 3-way call. I have two active call legs and I want to join the two remote endpoints using REFER. Everything else is just a special case of this problem. > > > The Contact that C provided to A is only guaranteed to make sense > > > in the context of A's session with C. [...] > > > > I disagree with this. The contact that C provided has to be > > available at least for new calls within the local namespace, and > > if not, then whatever translator in the middle (outbound proxy, > > transparent masquerade host or whatever) has to know to check the > > Refer-To header and mangle it also. > > > > Otherwise this gets too complicated. > > I'm not sure what/who you're disagreeing with? The contact that C > provides has only to be valid for subsequent requests in that > call-leg. (I can't imagine anyone actually implementing it that way, > but afaict, that's all the spec requires). Since the call between A and C is pretty much guaranteed to be still going on, this pedantic UA seems even more ridiculous. For the sake of interoperability the URI that you put in a Contact should be available for requests from other UAs, and if you're a multi-user phone or gateway, it should probably also have a username. > > > Jonathan's suggested method is to place the contact that C gave to > > > A in the Accept-Contact header to increase the probability (not > > > ensure) that B reaches the same C-endpoint that A did. > > > > And put that as a header parameter in the URL given in the > > Refer-To header? This seems like a big hack, especially since the > > well known URL may not be known. > > You didn't comment on the hybrid approach at the end of the message. I > think it addresses the case you are wanting to solve (as the primary > usage even). The hyrbid approach you suggested was: 1) REFER B directly to the contact that C provided to A. 2) If it fails, REFER B to C's well known URL with an Accept-Contact header containing the contact that C provided to A. I found another problem with part 2: The proxy now has to do some funky matching to try and correlate the Contact provided with those known. Pretty crazy, since in your scenario it's not the same as how it registered, but I guess in some cases it is somehow similar (different port, host in the same subnet, etc). Of course, this is all implementation specific- there are probably other ways of convincing the transfer to work if it fails. It would be nice to eventually define some body type to indicate to the referrer why the call failed (application/sip-status?). However I would NOT recommend attempting step 2 as it is error-prone and only solves a very unlikely specific case. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 16:30:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29947 for ; Mon, 13 Nov 2000 16:30:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4EC0844356; Mon, 13 Nov 2000 15:30:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id D85F644352 for ; Mon, 13 Nov 2000 15:29:30 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id QAA02103; Mon, 13 Nov 2000 16:24:28 -0500 (EST) Message-ID: <3A105D12.D8DE8BF1@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: Neil Deason Cc: Sip List Subject: Re: [SIP] new torture tests References: <3A102B34.3F1FEEBC@ubiquity.net> Content-Type: multipart/alternative; boundary="------------EC43B8B7C90D7ACA4D51C223" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 13 Nov 2000 16:28:50 -0500 --------------EC43B8B7C90D7ACA4D51C223 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Hello! Tbanks for posting these (it has a laxative effect on my parser :). In particular, I like the fact that you have posted expected return messages (it would be useful if the previous list also had such information). I have a couple of questions on the following header where you have used escape sequences: Can the COLON in the sip: of the URI be an escaped sequence? Second, you have used %40 in place of the @ at the end of the user name. Is this legal? If this is legal, then there is no way for the user to use an escape sequence for part of his or her name. Regards Ranga. > > > 4) Legal SIP URL in Request URI with escaped characters and > parameter. > > INVITE sip%3Auser%40company.com;other-param=summit SIP/2.0 > To: sip:user@company.com > From: sip:caller@university.edu > Call-ID: 4@10.0.0.1 > CSeq: 1 INVITE > Via: SIP/2.0/UDP 135.180.130.133 > Content-Type: application/sdp > Content-Length: 174 > > v=0 > o=mhandley 29739 7272939 IN IP4 126.5.4.3 > s=SIP Call > t=3149328700 0 > c=IN IP4 135.180.130.88 > m=audio 492170 RTP/AVP 0 12 > m=video 3227 RTP/AVP 31 > a=rtpmap:31 LPC > > -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------EC43B8B7C90D7ACA4D51C223 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello!
 

Tbanks for posting these (it has a laxative effect on my parser :).   In particular, I like the fact that you have posted expected return messages (it would be useful if the previous list also had such information).  I have a couple of questions on the following header where you have used escape sequences:

Can the COLON in the sip: of the URI be an escaped sequence?

Second, you have used %40 in place of the @ at the end of the user name. Is this legal?  If this is legal, then   there is no way for the user to use an escape sequence for part of his or her name.

Regards

Ranga.



 

4) Legal SIP URL in Request URI with escaped characters and
parameter.

INVITE sip%3Auser%40company.com;other-param=summit SIP/2.0
To: sip:user@company.com
From: sip:caller@university.edu
Call-ID: 4@10.0.0.1
CSeq: 1 INVITE
Via: SIP/2.0/UDP 135.180.130.133
Content-Type: application/sdp
Content-Length: 174

v=0
o=mhandley 29739 7272939 IN IP4 126.5.4.3
s=SIP Call
t=3149328700 0
c=IN IP4 135.180.130.88
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
 
 

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------EC43B8B7C90D7ACA4D51C223-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 17:21:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15956 for ; Mon, 13 Nov 2000 17:21:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 286714436E; Mon, 13 Nov 2000 16:21:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id D7C464436E for ; Mon, 13 Nov 2000 16:20:31 -0500 (EST) Received: from Pradeep (w040.z208176180.sjc-ca.dsl.cnc.net [208.176.180.40]) by westhost16.westhost.net (8.8.5/8.8.5) with SMTP id QAA17140 for ; Mon, 13 Nov 2000 16:24:28 -0600 From: "Tom Tang" 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] SIP End-2-End Security Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 14:01:07 -0800 Content-Transfer-Encoding: 7bit Hello : I am wondering what mechanisms companies are planning to deploy for SIP security. I've been hearing PGP and TLS mainly, but I didn't see any postings for extensions to either protocols. Please tell me if I've skipped over some draft. Thanks. - Tom Tang Tom Tang IP Unity 1575 McCandless Drive Milpitas, CA 95035 (408) 957-0800 x154 (w) (408) 957-0823 (f) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 17: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 SMTP id RAA19526 for ; Mon, 13 Nov 2000 17:32:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 65C5644377; Mon, 13 Nov 2000 16:32:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9BE254433B for ; Mon, 13 Nov 2000 16:31:20 -0500 (EST) 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 RAA08846; Mon, 13 Nov 2000 17:33:32 -0500 (EST) From: "Robert Sparks" To: "Billy Biggs" Cc: Subject: RE: [SIP] Possible REFER problem? 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: <20001113152656.A26717@div8.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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, 13 Nov 2000 16:29:35 -0600 Content-Transfer-Encoding: 7bit > > > > The Contact that C provided to A is only guaranteed to make sense > > > > in the context of A's session with C. [...] > > > > > > I disagree with this. The contact that C provided has to be > > > available at least for new calls within the local namespace, and > > > if not, then whatever translator in the middle (outbound proxy, > > > transparent masquerade host or whatever) has to know to check the > > > Refer-To header and mangle it also. > > > > Jonathan's suggested method is to place the contact that C gave to > > > > A in the Accept-Contact header to increase the probability (not > > > > ensure) that B reaches the same C-endpoint that A did. > > > > > > And put that as a header parameter in the URL given in the > > > Refer-To header? This seems like a big hack, especially since the > > > well known URL may not be known. > > > > You didn't comment on the hybrid approach at the end of the message. I > > think it addresses the case you are wanting to solve (as the primary > > usage even). > > The hyrbid approach you suggested was: > > 1) REFER B directly to the contact that C provided to A. > 2) If it fails, REFER B to C's well known URL with an Accept-Contact > header containing the contact that C provided to A. > > I found another problem with part 2: The proxy now has to do some > funky matching to try and correlate the Contact provided with those > known. Pretty crazy, since in your scenario it's not the same as how it > registered, but I guess in some cases it is somehow similar (different > port, host in the same subnet, etc). Actually, in this scenario it would likely be _exactly_ what was registered. This is one of the premises of caller-prefs, yes? The funky matching is defined in that draft. If for some reason, it wasn't registered, or the proxy involved didn't implement caller-prefs, the proxy's going to route to the same places it would have without the hint. > > However I would NOT recommend attempting step 2 as it is error-prone > and only solves a very unlikely specific case. We _must_ be talking past each other here. What's proposed at 2 is a straightforward use of the caller-preferences mechanism. At the absolute worst, 2 will result in exactly what you would have gotten if the REFER to B contained only C's well known 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 Nov 13 17:36: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 RAA20570 for ; Mon, 13 Nov 2000 17:36:38 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C1DD44395; Mon, 13 Nov 2000 16:34:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by lists.bell-labs.com (Postfix) with ESMTP id 2DDA944393 for ; Mon, 13 Nov 2000 16:33:52 -0500 (EST) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id OAA09697; Mon, 13 Nov 2000 14:33:31 -0800 (PST) Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 13 Nov 2000 22:33:30 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 14:33:29 -0800 Message-ID: From: "Agarwal, Aseem" To: "'caseyong@krdl.org.sg'" Cc: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 13 Nov 2000 14:33:27 -0800 Hi, Has the following draft been updated ? Is YES, please point me to the latest version available. "The SIP PROPOSE Method", draft-onghe-mmusic-sip-propose-00.txt, Jun 1999 thanks, aseem _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 18:05: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 SAA27212 for ; Mon, 13 Nov 2000 18:05:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C91374436E; Mon, 13 Nov 2000 17:05:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 5D79B4436A for ; Mon, 13 Nov 2000 17:04:32 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 13 Nov 2000 17:04:12 -0600 (CST) From: Billy Biggs To: Robert Sparks Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Possible REFER problem? Message-ID: <20001113170412.A26810@div8.net> References: <20001113152656.A26717@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from rsparks@dynamicsoft.com on Mon, Nov 13, 2000 at 04:29:35PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 13 Nov 2000 17:04:12 -0600 Robert Sparks (rsparks@dynamicsoft.com): > > The hyrbid approach you suggested was: > > > > 1) REFER B directly to the contact that C provided to A. > > 2) If it fails, REFER B to C's well known URL with an > > Accept-Contact header containing the contact that C provided to > > A. > > > > I found another problem with part 2: The proxy now has to do some > > funky matching to try and correlate the Contact provided with > > those known. Pretty crazy, since in your scenario it's not the > > same as how it registered, but I guess in some cases it is somehow > > similar (different port, host in the same subnet, etc). > > Actually, in this scenario it would likely be _exactly_ what was > registered. [...] At the absolute worst, 2 will result in exactly > what you would have gotten if the REFER to B contained only C's well > known URL. I'm sorry, there were two discussed scenarios where this would be needed, and I got confused: Case 1 (what you meant): > [...] the hostname may be in a private namespace in a company's LAN. -> Refer-To: The refer failed because the Contact was a private address, and hopefully it was the same address used to register at well-known.com. You are correct, this will help well-known.com reach the private address. Apologies. Case 2 (my confusion): > [...] The contact that C provides has only to be valid for subsequent > requests in that call-leg. -> Refer-To: Here we have a UA which fork()s off a new process per call which has its own port. Caller-preferences does nothing, but you are correct in that it doesn't hurt. However, I think this just makes the algorithm over-complicated. You're making an assumption about why the original REFER failed when there are many other possible explinations: - The REFER target returned a 486 or other error response - The REFER target has a sever failure - Some authentication failure - ... It also only works if A initiated the call to C. Like I said, implementations are free to try harder, but I wouldn't recommend it. Note that I plan on hacking my masquerade module code to also mangle the Refer-To header. That's the bane of the NAT implementor- to forever be modifying the NAT code to handle the new protocol or protocol extension. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 20:01: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 UAA26098 for ; Mon, 13 Nov 2000 20:01:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 41AEC44359; Mon, 13 Nov 2000 19:01:07 -0500 (EST) 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 5147A44350 for ; Mon, 13 Nov 2000 19:00:26 -0500 (EST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id BAA26950 for ; Tue, 14 Nov 2000 01:01:26 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 14 Nov 2000 01:00:06 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 17:00:04 -0800 Message-ID: From: "Schmidlin, David" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Redirect VS Proxy Server Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 13 Nov 2000 16:59:49 -0800 Why/Where would you use a redirect server over a proxy server and vice versa? Thanks, Dave David J Schmidlin Ext. 4869 JF3-2-D8 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 20:39:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04421 for ; Mon, 13 Nov 2000 20:39:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 050E144363; Mon, 13 Nov 2000 19:39:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 2C9CA44359 for ; Mon, 13 Nov 2000 19:38:14 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 13 Nov 2000 19:37:54 -0600 (CST) From: Billy Biggs To: "Schmidlin, David" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Redirect VS Proxy Server Message-ID: <20001113193754.A26947@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from david.schmidlin@intel.com on Mon, Nov 13, 2000 at 04:59:49PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 13 Nov 2000 19:37:54 -0600 Schmidlin, David (david.schmidlin@intel.com): > Why/Where would you use a redirect server over a proxy server and vice > versa? If you were a web server, when would you send a redirect and when would you proxy? It's the same answer. Redirect servers are cheap to code, for one. But these are logical roles not separate entities, so your question should be more specific. In general you proxy a message when you are providing some additional feature rather than simply performing a lookup. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 13 21:51:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23163 for ; Mon, 13 Nov 2000 21:51:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9CF3444359; Mon, 13 Nov 2000 20:51:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B05B344339 for ; Mon, 13 Nov 2000 20:50:34 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA10617; Mon, 13 Nov 2000 21:52:48 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YYSV>; Mon, 13 Nov 2000 21:48:54 -0500 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , Sip List Subject: RE: [SIP] new torture tests 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, 13 Nov 2000 21:48:48 -0500 Comments below. > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Monday, November 13, 2000 12:56 PM > To: Sip List > Subject: [SIP] new torture tests > > > The following are 15 new proposed torture test messages > based on the bis draft. None of them should cause good > implementations to crash. Recommended responses to the > illegal messages are given where needed. Well, some of your messages have only mild errors in them. Based on the philosophy of being liberal with what you receive, I would not declare an entity to have failed the test if it does not generate the specific error code. > 1) Illegal enclosing of Request-URI in "<>" > Server should respond with 400 + Appropriate Reason Phrase. > > INVITE SIP/2.0 > To: sip:user@company.com > From: sip:caller@university.edu > Call-ID: 1@10.0.0.1 > CSeq: 1 INVITE > Via: SIP/2.0/UDP 135.180.130.133 > Content-Type: application/sdp > Content-Length: 174 > > v=0 > o=mhandley 29739 7272939 IN IP4 126.5.4.3 > s=SIP Call > t=3149328700 0 > c=IN IP4 135.180.130.88 > m=audio 492170 RTP/AVP 0 12 > m=video 3227 RTP/AVP 31 > a=rtpmap:31 LPC > > > 2) Illegal LWS in elements of Request-URI > Server should respond with 400 + Appropriate Reason Phrase. > > INVITE sip:user@company.com; transport=udp SIP/2.0 > To: sip:user@company.com > From: sip:caller@university.edu > Call-ID: 2@10.0.0.1 > CSeq: 1 INVITE > Via: SIP/2.0/UDP 135.180.130.133 > Content-Type: application/sdp > Content-Length: 174 > > v=0 > o=mhandley 29739 7272939 IN IP4 126.5.4.3 > s=SIP Call > t=3149328700 0 > c=IN IP4 135.180.130.88 > m=audio 492170 RTP/AVP 0 12 > m=video 3227 RTP/AVP 31 > a=rtpmap:31 LPC I suspect many implementations will accept the above message. > > > 3) Illegal >1 SP between elements of Request URI > Server should respond with 400 + Appropriate Reason Phrase. > > INVITE sip:user@company.com SIP/2.0 > To: sip:user@company.com > From: sip:caller@university.edu > Call-ID: 3@10.0.0.1 > CSeq: 1 INVITE > Via: SIP/2.0/UDP 135.180.130.133 > Content-Type: application/sdp > Content-Length: 174 > > v=0 > o=mhandley 29739 7272939 IN IP4 126.5.4.3 > s=SIP Call > t=3149328700 0 > c=IN IP4 135.180.130.88 > m=audio 492170 RTP/AVP 0 12 > m=video 3227 RTP/AVP 31 > a=rtpmap:31 LPC Same here. > 5) Illegal use of escaped header in Request-URI > Proxies should strip off the escaped header before proxying on. > > INVITE sip:user@company.com?Route=%3Csip:sip.example.com%3E > SIP/2.0 > To: sip:user@company.com > From: sip:caller@university.edu > Call-ID: 5@10.0.0.1 > CSeq: 1 INVITE > Via: SIP/2.0/UDP 135.180.130.133 > Content-Type: application/sdp > Content-Length: 174 > > v=0 > o=mhandley 29739 7272939 IN IP4 126.5.4.3 > s=SIP Call > t=3149328700 0 > c=IN IP4 135.180.130.88 > m=audio 492170 RTP/AVP 0 12 > m=video 3227 RTP/AVP 31 > a=rtpmap:31 LPC I'm not sure I agree with the behavior here. If the proxy is not company.com, it may simple forward the request to company.com without stripping the Route header. I see nothing wrong with that. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 02:40: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 CAA09522 for ; Tue, 14 Nov 2000 02:40:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8414244339; Tue, 14 Nov 2000 01:40:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 087C144336 for ; Tue, 14 Nov 2000 01:39:28 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V797M22N; Tue, 14 Nov 2000 08:37:10 +0100 From: "Hisham Khartabil" To: "Pete Kazmier" , Subject: RE: [SIP] Gateway and Redirected Number Question Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20001113113321.C17325@kazmier.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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 09:40:42 +0200 Content-Transfer-Encoding: 7bit Check this out http://www.cs.columbia.edu/sip/drafts_pstn.html there are a number of internet drafts there. Regards, Hisham Khartabil Hotsip Finland -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Pete Kazmier Sent: Monday, 13 November 2000 6:33 PM To: sip@lists.bell-labs.com Subject: [SIP] Gateway and Redirected Number Question If a PSTN originated call is redirected to a gateway, how would, for example, a Q.931 redirected number or SS7 RDN/OCN be mapped into a SIP INVITE message? I've been looking through various drafts to determine the appropriate action but I can't seem to find the right one. Could somone point me in the right direction? Thanks. -- Peter Kazmier http://www.kazmier.com PGP Fingerprint 4FE7 8DA3 D0B5 9CAA 69DC 7243 1855 BC2E 4B43 5654 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 14 04:06: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 EAA15660 for ; Tue, 14 Nov 2000 04:06:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5EBD644339; Tue, 14 Nov 2000 03:06:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 0B7F644336 for ; Tue, 14 Nov 2000 03:05:00 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE90aJ03267; Tue, 14 Nov 2000 18:00:36 +0900 Message-ID: <01e801c04e19$e5c33b60$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: "Henning Schulzrinne" Cc: "Jonathan Rosenberg" , , Subject: RE: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00ED_01C04E65.3BEFAB40" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:00:36 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_00ED_01C04E65.3BEFAB40 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Henning: > Since To and From are used to match call legs, they can't be = replicated. > (Besides minor problems like breaking every single existing SIP > implementation...) Unlike for email, which can easily be copied, SIP > call legs need a single destination. SMTP, after all, also does two > transactions if you put in two different To fields. > > > > > Since this information only affects the display of call requests and = reply > > functionality I don't see the difficulty in implementing this. What > problems can you > > see? (I havn't though about the implications for comparing requests = to > see if they > > are the same). > > That's one of the complications. > > SIP is not email, so doing a plain carry-over of headers is not likely > to work well. > > Adding informational headers that carry no protocol implications is > relatively harmless. For example, "Reply-To" might be a way to = indicate > addresses for possible return calls. The Also-To: header would be purely informational - it would indicate to = the UAS what other UASs had been invited. The meaning of Reply-To: is different from = From: - and this difference could be just as useful for IMs and voice calls as it is = for e-mail. IMs in particular, due to their close similarity to e-mail, should = retain the same features users are used to with e-mail. My question is why should users = lose this functionality for either IMs or voice calls? Simon Barber ------=_NextPart_000_00ED_01C04E65.3BEFAB40 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_00ED_01C04E65.3BEFAB40-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:07: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 EAA16405 for ; Tue, 14 Nov 2000 04:07:48 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9EF444340; Tue, 14 Nov 2000 03:06:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 983DA44339 for ; Tue, 14 Nov 2000 03:05:02 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91AJ03482; Tue, 14 Nov 2000 18:01:11 +0900 Message-ID: <02a101c04e19$f86b3ba0$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: , , Subject: Re: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_014F_01C04E65.4AED4120" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:11 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_014F_01C04E65.4AED4120 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, This is something I've also been looking into.=20 One way would be to add a new header (e.g. Also-From). That header could be inserted by a proxy that does know the request may end up in a gateway. The UA may not know that, so he could put whatever string in the user part of the From header (e.g. his e-mail address). If the proxy then knows the UAs telephone number, for example by using some kind of database lookup, which is needed by the gateway - for any possible A-number procedure - the proxy can add that to the request. Another way would be to just define a URI parameter for the From header, but the bad thing about that is that it can not be inserted by a proxy if it was not in the request from the UA (since the From header must not be changed) by a proxy, or any other intermediate node. Note, that this response is according to Clive's mail. I do NOT support the idea of ALSO-TO headers, multiple FROM/TO headers and whatever was proposed in the previous mails :) Regards, Christer Holmberg Ericsson Finland clive.dellard@bt.com wrote: >=20 > I agree with what you say, however, if you consider a call originating = from > a SIP device (telephone or softphone) that ends up going through a = gateway > to the PSTN then it is a different story. > Neither the user or the UAC can know where a call will end up, = therefore the > ability to be able to provide both SIP address and SIP Telephone = number > would be useful to providing a complete service as then an appropriate > calling address is available wherever the call ends up. In the = scenario I > described the gateway could chose the Telephone number (ok I know = there are > verification issues but that's another story). > Something like Simon's idea of an "ALSO-FROM" seems a good idea to me = (this > is similar to "two number delivery" in the ISDN CLIP service) older = versions > would just ignore the ALSO-FROM and it wouldn't affect the = significance of > the FROM and TO headers. >=20 > Clive >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > > Sent: Wednesday, October 11, 2000 7:41 PM > > To: 'clive.dellard@bt.com'; 'sip@lists.bell-labs.com' > > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > -----Original Message----- > > > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > > > Sent: Wednesday, October 11, 2000 12:17 PM > > > To: sip@lists.bell-labs.com > > > Subject: [SIP] From header to ISUP CgPN mapping > > > > > > > > > In the call flows document draft-ietf-sip-call-flows-01.txt, > > > scenario 4.1.1, > > > the message detail and text show User A using a SIP telephone > > > number rather > > > than a SIP address in the From header. The text at the > > > beginning of section > > > 4 also says "that User A still uses his/her SIP URL in the > > > Contact header, > > > since the call could be redirected back to the SIP network." > > > This implies that User A has pre-knowledge that the call is > > > going to route > > > to the PSTN and has the ability to chose the address to be > > > used in the From > > > header. > > > > No. > > > > The From header is the logical identity of the user making the call. = Since > > the call is coming through a gateway, that user is some user on a = PSTN > > terminal somewhere. The identity in this case can either be a tel = URL, or > > a > > SIP URL at the domain of the originating network. > > > > The Contact is used for signaling addressing. Its not a logical > > identifier. > > It answers the question "where should I send SIP messages to for the = rest > > of > > this call". The SIP spec says this is supposed to be a SIP URL = preferably > > with a complete hostname, so that there are no ambiguities about = where to > > send requests. > > > > Neither of these have anything to do with knowing where the call is = going. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com >=20 > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_014F_01C04E65.4AED4120 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_014F_01C04E65.4AED4120-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04: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 EAA17359 for ; Tue, 14 Nov 2000 04:10:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E8E644345; Tue, 14 Nov 2000 03:06:34 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id DE28144336 for ; Tue, 14 Nov 2000 03:05:07 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91HJ03490 for ; Tue, 14 Nov 2000 18:01:17 +0900 Message-ID: <02d101c04e19$fbb27760$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Subject: [SIP] Contiguos CSeq number MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_015B_01C04E65.4B7B2940" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:17 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_015B_01C04E65.4B7B2940 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, I have a question about the CSeq number value. Consider the following case: A UAC sends a request to a UAS using CSeq=1. The UAC then sends another request to the same UAS using CSeq=2. However, for some reason the UAS never gets the request. It may, for example, be terminated by an intermediate proxy, sending a response to it, or it may be cancelled before it reaches the UAS. After that, the UAC sends a third request, using CSeq=3, to the UAS. So, the UAS will receive two requests, the first and the third, but not the second. Chapter 6.20 in the RFCbis says that the CSeq number must be contiguous. However, in this case the UAS will never receive the second request. Should it "wait" for it (it will never arrive...) or what is the purpose of the line in the RFCbis? Regards, Christer Holmberg Ericsson Finland ------=_NextPart_000_015B_01C04E65.4B7B2940 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_015B_01C04E65.4B7B2940-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:12: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 EAA18381 for ; Tue, 14 Nov 2000 04:12:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB22344349; Tue, 14 Nov 2000 03:06:46 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id EEAE944336 for ; Tue, 14 Nov 2000 03:05:10 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91IJ03497; Tue, 14 Nov 2000 18:01:18 +0900 Message-ID: <02e701c04e19$fd7f4820$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Lars Berggren" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0171_01C04E65.4D5A4980" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:18 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0171_01C04E65.4D5A4980 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >>Hi, >> >>First, this mail is NOT a proposal for a change. I would just like to >>hear some opinions - or maybe it has already been discussed on the = list? >> >>The INFO Method RFC says that for INFO requests without a message = body, >>a server supporting INFO MUST respond with response code 200. So, my >>question is: why couldn't INFO be used for the session-timer >>functionality? Is the ACK the (re-)INVITE provides really necessary = for >>the purpose? >> >>And, like the session-timer is defined now, the other party would not >>even have to support the INFO method, because a 501 Not Implemented >>would be sent, and the sender of the INFO would know the session is >>"alive". >> >>Just some thoughts... Please let me know if there is something I = haven't >>taken into consideration. >> >=20 >I think the re-INVITE mechanism is far more better because the = >information about what session is refreshed is carried in the SDP of = the >re-INVITE. The INFO approach has the significant disadvantage that = >proxies that use the session timer might have to store a *lot* of state >information about each session. That is not true. The session is identified using the Call-ID. In fact, another advantage of using INFO is that you don't have to send a message body at all. Using re-INVITE, you must send a copy of the original message, and the UAS must check if the SDP is a copy (session-timer) or if it is a new SDP, when the session should be modified. Again, we save resources. Comments? Regards, Christer Holmberg Ericsson Finland >=20 > Regards /Lars >=20 > > Regards, > > > > Christer Holmberg > > Ericsson Finland >=20 > Lars Berggren > Intertex Data AB tel: +46-8-6282828 > Sundbyberg, Sweden fax: +46-8-6286414 ------=_NextPart_000_0171_01C04E65.4D5A4980 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0171_01C04E65.4D5A4980-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:15: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 EAA19659 for ; Tue, 14 Nov 2000 04:15:35 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 941EA4434F; Tue, 14 Nov 2000 03:06:58 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 5813D44339 for ; Tue, 14 Nov 2000 03:05:11 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91KJ03501; Tue, 14 Nov 2000 18:01:20 +0900 Message-ID: <02e901c04e19$fdc26ba0$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: "SIP" Cc: "Anders Kristensen" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0177_01C04E65.4D837C60" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:20 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0177_01C04E65.4D837C60 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, I found the archive, and the thread. The discussion was very much about the fact that by using re-INVITEs the session can be "automatically" re-established if the UAS has booted, and I guess this works fine as long as we don't get any 18x responses, which may include ringtones, messages and who knows what (we may even receive a 3xx Redirect message) And, if the UAC uses INFO, and receive 481 Call leg/Transaction Does Not Exist (e.g. if the UAS has booted), it can choose to send a re-INVITE, and be prepared to receive 18x messages, to reestablish the session. Also, I don't think the UAS will crash that often, compared to what we would save by not having to send ACKs etc. Regards, Christer Holmberg Ericsson Finland Anders Kristensen wrote: >=20 > We had this whole discussion about a year ago. Unfortunately the > archives doesn't seem to go that far back, but it seems pointless to > repeat that discussion. Is there an archive somewhere for the old = list? >=20 > Anders >=20 > Christer Holmberg wrote: > > > > Hi, > > > > Thanks for the comments! > > > > >If the UA crashed and rebooted and forgot about the old session, it = would > > >respond with either a 481 call leg doesn't exist (you would know = the call > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > >thanks, > > >-rohan > > > > I think that would be good, because then we could inform the user = that > > the call doesn't exist anymore. > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > session-timer re-INVITE. If the UAS has forgotten about the old = session > > it would consider the re-INVITE as a new INVITE, for a new session. = It > > would try to establish a new session - and we could suddenly start > > receiving provisional 18x responses (with or without SDP bodies), = and/or > > a 200 response with a SDP body, to the session-timer re-INVITE. What = do > > we do then? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > >Hi, > > > > > > > >First, this mail is NOT a proposal for a change. I would just = like to > > > >hear some opinions - or maybe it has already been discussed on = the list? > > > > > > > >The INFO Method RFC says that for INFO requests without a message = body, > > > >a server supporting INFO MUST respond with response code 200. So, = my > > > >question is: why couldn't INFO be used for the session-timer > > > >functionality? Is the ACK the (re-)INVITE provides really = necessary for > > > >the purpose? > > > > > > > >And, like the session-timer is defined now, the other party would = not > > > >even have to support the INFO method, because a 501 Not = Implemented > > > >would be sent, and the sender of the INFO would know the session = is > > > >"alive". > > > > > > > >Just some thoughts... Please let me know if there is something I = haven't > > > >taken into consideration. > > > > > > > >Regards, > > > > > > > >Christer Holmberg > > > >Ericsson Finland > > > > >=20 > -- > Anders Kristensen ------=_NextPart_000_0177_01C04E65.4D837C60 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0177_01C04E65.4D837C60-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:17:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20594 for ; Tue, 14 Nov 2000 04:17:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CABC44355; Tue, 14 Nov 2000 03:07:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id CC3D54433B for ; Tue, 14 Nov 2000 03:05:11 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91KJ03504; Tue, 14 Nov 2000 18:01:20 +0900 Message-ID: <02ef01c04e19$fdfc6760$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: "SIP" Cc: "Anders Kristensen" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_017C_01C04E65.4DA50E20" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:20 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_017C_01C04E65.4DA50E20 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >I actually agree with you (except I would have used a new method rather >than INFO). That is of course an option. I just thought that INFO, with no message body, would work fine, since the only thing the UAS has to do is to send a response (no communication with the user/application is required). >I just don't think it's very likely, given that the arguments are = largely unchanged, that people will be >willing to modify the session = timer mechanism at this late stage. There are different ways of doing it. IF you would choose to change the current specification, basically the only thing you would have to do is to change the re-INVITEs to INFOs (or whatever method you choose to use). The negotiation mechanism of the timer value, the extension headers etc. would remain. Of course, a UA who wishes to send INFOs would also have to support the method. Another way would be to define a new mechanism - "session ping", "session-timer light", or whatever you want to call it :) >Anyway, maybe you should post the archive pointer and then we can at = least have a fully informed discussion. The link to the archieve is...=20 http://www.bell-labs.com/mailing-lists/sip/20000/subject.html ...and the subject is 'Session timer comments'. Regards, Christer Holmberg Ericsson Finland >=20 > Anders >=20 > Christer Holmberg wrote: > > > > Hi, > > > > I found the archive, and the thread. The discussion was very much = about > > the fact that by using re-INVITEs the session can be "automatically" > > re-established if the UAS has booted, and I guess this works fine as > > long as we don't get any 18x responses, which may include ringtones, > > messages and who knows what (we may even receive a 3xx Redirect = message) > > And, if the UAC uses INFO, and receive 481 Call leg/Transaction Does = Not > > Exist (e.g. if the UAS has booted), it can choose to send a = re-INVITE, > > and be prepared to receive 18x messages, to reestablish the session. > > > > Also, I don't think the UAS will crash that often, compared to what = we > > would save by not having to send ACKs etc. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Anders Kristensen wrote: > > > > > > We had this whole discussion about a year ago. Unfortunately the > > > archives doesn't seem to go that far back, but it seems pointless = to > > > repeat that discussion. Is there an archive somewhere for the old = list? > > > > > > Anders > > > > > > Christer Holmberg wrote: > > > > > > > > Hi, > > > > > > > > Thanks for the comments! > > > > > > > > >If the UA crashed and rebooted and forgot about the old = session, it would > > > > >respond with either a 481 call leg doesn't exist (you would = know the call > > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > > > >thanks, > > > > >-rohan > > > > > > > > I think that would be good, because then we could inform the = user that > > > > the call doesn't exist anymore. > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > session-timer re-INVITE. If the UAS has forgotten about the old = session > > > > it would consider the re-INVITE as a new INVITE, for a new = session. It > > > > would try to establish a new session - and we could suddenly = start > > > > receiving provisional 18x responses (with or without SDP = bodies), and/or > > > > a 200 response with a SDP body, to the session-timer re-INVITE. = What do > > > > we do then? > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > >Hi, > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would just = like to > > > > > >hear some opinions - or maybe it has already been discussed = on the list? > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a = message body, > > > > > >a server supporting INFO MUST respond with response code 200. = So, my > > > > > >question is: why couldn't INFO be used for the session-timer > > > > > >functionality? Is the ACK the (re-)INVITE provides really = necessary for > > > > > >the purpose? > > > > > > > > > > > >And, like the session-timer is defined now, the other party = would not > > > > > >even have to support the INFO method, because a 501 Not = Implemented > > > > > >would be sent, and the sender of the INFO would know the = session is > > > > > >"alive". > > > > > > > > > > > >Just some thoughts... Please let me know if there is = something I haven't > > > > > >taken into consideration. > > > > > > > > > > > >Regards, > > > > > > > > > > > >Christer Holmberg > > > > > >Ericsson Finland > > > > > > > > > > > > -- > > > Anders Kristensen ------=_NextPart_000_017C_01C04E65.4DA50E20 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_017C_01C04E65.4DA50E20-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:20: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 EAA21645 for ; Tue, 14 Nov 2000 04:20:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B30B14435C; Tue, 14 Nov 2000 03:07:21 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 555644433C for ; Tue, 14 Nov 2000 03:05:12 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91LJ03509; Tue, 14 Nov 2000 18:01:21 +0900 Message-ID: <02f501c04e19$fe5053c0$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "hammer michael" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0180_01C04E65.4DB5D700" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:21 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0180_01C04E65.4DB5D700 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, If I send you an INFO, or any other method that you don't support, you can for example send a 501 Not Implemented response, and include an Allow header with the methods you support. Of course, you can't stop the UAC of sending the method again, if he chooses to... You can not, however, tell an UAC not to send you re-INVITEs, because then you would also forbid the UAC to send you INVITEs - and I don't think you want to do that. Also, the specification says that a UA MUST be able to receive INVITEs (which included re-INVITEs), so... Regards, Christer Holmberg Ericsson Finland hammer michael wrote: >=20 > Is this the Internet version of "let them eat cake?" Signal-spam is = not > more palatable than the normal variety. >=20 > Is there a response code that can indicate the sentiment: I don't = support > this method, don't try it again? It might also be good to make sure = that > such undesirable sub-methods are indicated as "Unsupported." If that > sub-method is well-defined, then that header parameter should be = applicable. >=20 > Mike >=20 > At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote: >=20 > >Hi, > > > > >Good points. Here's one more problem you may want to consider. > > >Whenever you invoke a ping-style method of deciding if a session is > > >alive, you open up problems due to network jitter and bandwidth. = For > > >instance, you could easily have a packet delayed at an endpoint due = to > > >a large file transfer starting up, or some other bandwidth = consuming > > >event. In this case, your ping could be delayed long enough to = cause > > >the session to drop for no good reason. > > > >Well, this could be the case no matter which method (INVITE, INFO, or > >whatever...) you use in the heartbeat request... > > > > >You're also creating the potential for artificial problems in = wireless > > >networks by using a ping-method to keep a session alive. During a > > >handover there may be a period where packets are in effect "muted" = for > > >a short period of time. The mute period may not, by itself be long > > >enough to trigger a ping-timer to pop and kill the session, but if = the > > >ping was near the edge of the time envelope to be accepted as > > >"on-time" anyhow, once again, your session could very easily drop = when > > >the media was operating just fine. > > >Also, keep in mind, the longer you set the ping timer for, the more > > >network resources you will likely waste over time because of the > > >additional latentcy in discovering a "dead" session. > > > >Just to clarify, this "ping-method" IS already defined for SIP > >(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to = ping. > >My idea was about replacing the re-INVITE with INFO, which mean we = would > >actually save resources since we don't have to send ACK every time. > > > > >This method has one other nasty side-effect. You'd be wasting = network > > >resources on an event that will likely not occur very often. After > > >all, every INFO exchange except the very last one that invalidates = the > > >session could have very well not been sent without any negative = impact > > >on the session (otherwise they would have been the last one). So > > >you've got proxies and UAs, and other transport resources being = tied > > >up processing packets that by and large are providing no value, and > > >they're chewing up bandwidth budget that other services could be = using > > >instead. > > > >That is an interesting point, and it is valid also for a number of = other > >SIP extensions where extra messages are sent (e.g. PRACK), but it is > >another discussion. > > > > >Please keep in mind that not everyone is looking at implementing = SIP > > >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous = numbers > > >of users), pinging and triangle-routing can be the death-knell of > > >these sorts of networks. > > > >Who said "bandwidth is free"? :) > > > > >Because of all of this, I think it would be a very bad idea for a = UA > > >to send an INFO to a client who repeatedly tells him "I don't > > >understand INFO" to see if he's alive. > > > >The number of messages on the network will be the same no matter if = we > >send an INVITE which he understands, or an INFO he may not = understand. > >Also, when we receive the response for the INVITE we also have to = send > >back an ACK, which is not the case when INFO is used. > > > > >He may not understand INFO because that particular network doesn't > > deem >the bandwidth required for this mechanism as being best used = for > > that >purpose. If someone tells you "don't send me this method" then > > don't send >it to them. > > > >Again, this has nothing to do with the bandwith issue. Even if I send > >re-INVITEs, which the other party understands, he can not tell me not = to > >send any more re-INVITEs. > > > > >Otherwise your implementation may be viewed as favorably as the = record > > >clubs that used to require you to send them a card every month = telling > > >them not to send you anything by some groups. > > > >Well, it's not up to me to decide when and if an operator will use = the > >session-timer, as defined in the draft, or not - I am just trying to > >make it as good (and less resource consuming) if he choses to. > > > >Regards, > > > >Christer Holmberg > >Ericsson Finland > > > > > > > > > > Brian Stucker > > > Nortel Networks > > > > > > -----Original Message----- > > > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > > > Sent: Monday, October 16, 2000 3:38 PM > > > To: Christer Holmberg; sip@lists.bell-labs.com > > > Cc: Rohan Mahy > > > Subject: RE: [SIP] Session-timer with INFO > > > > > > Some things to think about. > > > > > > I believe INFO is _not_ to be used to modify the state of a = session. > > > I > > > suppose a debate is possible about session-timer affecting session > > > state - present vs. future and if INFO is only restricted to one. = But > > > it's > > > probably best to leave it alone. Also, the INV-200-ACK exchange > > > allows multiple parties to agree on the duration of the session. = If > > > the > > > recipient of the INFO request wants a smaller value (because its > > > heartbeat interval is shorter) for the session timer it would have = to > > > send its own INFO request (unless you plan to keep the proposed > > > Session-expires header and its use in a 200 OK). Now four > > > messages are needed. In addition, there may be proxy issues when > > > using INFO. There's other behavior described in the draft too. > > > > > > > -----Original Message----- > > > > From: Christer Holmberg = [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Monday, October 16, 2000 3:42 PM > > > > To: sip@lists.bell-labs.com > > > > Cc: Rohan Mahy > > > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > > > > > > > > > Hi, > > > > > > > > Thanks for the comments! > > > > > > > > >If the UA crashed and rebooted and forgot about the old = session, it > > > > > > > would > > > > >respond with either a 481 call leg doesn't exist (you would = know > > > the > > > > call > > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > > > >thanks, > > > > >-rohan > > > > > > > > I think that would be good, because then we could inform the = user > > > that > > > > the call doesn't exist anymore. > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > session-timer re-INVITE. If the UAS has forgotten about the old > > > > session > > > > it would consider the re-INVITE as a new INVITE, for a new = session. > > > It > > > > would try to establish a new session - and we could suddenly = start > > > > receiving provisional 18x responses (with or without SDP = bodies), > > > > and/or > > > > a 200 response with a SDP body, to the session-timer re-INVITE. = What > > > > > > > do > > > > we do then? > > > > > > Well, you could ignore the provisional responses (you know the = other > > > end > > > is confused) and let the session get re-established or decide to > > > terminate > > > the session with CANCEL/BYE. > > > > > > Regards, > > > Bert > > > > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > >Hi, > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would just > > > like > > > > to > > > > > >hear some opinions - or maybe it has already been discussed = on > > > the > > > > list? > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a = message > > > > > > > body, > > > > > >a server supporting INFO MUST respond with response code 200. = So, > > > > > > > my > > > > > >question is: why couldn't INFO be used for the session-timer > > > > > >functionality? Is the ACK the (re-)INVITE provides really > > > necessary > > > > for > > > > > >the purpose? > > > > > > > > > > > >And, like the session-timer is defined now, the other party = would > > > > > > > not > > > > > >even have to support the INFO method, because a 501 Not > > > Implemented > > > > > >would be sent, and the sender of the INFO would know the = session > > > is > > > > > >"alive". > > > > > > > > > > > >Just some thoughts... Please let me know if there is = something I > > > > haven't > > > > > >taken into consideration. > > > > > > > > > > > >Regards, > > > > > > > > > > > >Christer Holmberg > > > > > >Ericsson Finland > > > > > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_0180_01C04E65.4DB5D700 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0180_01C04E65.4DB5D700-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:22: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 EAA22479 for ; Tue, 14 Nov 2000 04:22:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B96CA44361; Tue, 14 Nov 2000 03:07:33 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id D5A644433E for ; Tue, 14 Nov 2000 03:05:12 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91MJ03518; Tue, 14 Nov 2000 18:01:22 +0900 Message-ID: <02fa01c04e19$fea44020$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: , Subject: [SIP] SIP and T.38 fax calls - Internet Draft MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0186_01C04E65.4DCE4100" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:22 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0186_01C04E65.4DCE4100 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit A new Internet-Draft has been submitted, dealing with real time fax calls and SIP: call flows and BCP. Comments and suggestions are very much appreciated. Regards, Jean-Francois Mule -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, October 17, 2000 3:47 AM Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP T.38 Call Flow Examples And Best Current Practice Author(s) : J. Mule Filename : draft-mule-sip-t38callflows-00.txt Pages : 19 Date : 16-Oct-00 This document gives examples of SIP call flows for T.38 Internet fax communications (SIP, the Session Initiation Protocol is defined in RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and Gateways to the PSTN (Public Switch Telephone Network). This document introduces best current practices for T.38 fax calls: a call starts with audio capabilities, and, upon fax tone detection, T.38 fax capabilities are negotiated. The T.38 fax call scenarios include the detection of T.38 fax transmission by the receiving side, or the emitting side, or both (in the latter case, a 'glare' effect may appear). The current version of this document only covers the case when the fax tone is detected by the receiving side (other cases were left for discussion and may be included in the future). Call flow diagrams and message details are shown. A list of IANA defined SDP attribute names for T.38 is summarized in section 5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mule-sip-t38callflows-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mule-sip-t38callflows-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0186_01C04E65.4DCE4100 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0186_01C04E65.4DCE4100-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:24: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 EAA23389 for ; Tue, 14 Nov 2000 04:24:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A8E5B44340; Tue, 14 Nov 2000 03:08:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 493B044339 for ; Tue, 14 Nov 2000 03:05:14 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91NJ03533; Tue, 14 Nov 2000 18:01:23 +0900 Message-ID: <030701c04e19$ff7e7380$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Bryan Byerly" , , , , Subject: Re: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0194_01C04E65.4E7619C0" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:23 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0194_01C04E65.4E7619C0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, Using the Diversion header, you can inform an endpoint of which Request-URIs have been used before the Request-URI of that specific endpoint was used. The case I am talking about, however, is when we can insert an "alias" header for the From header, using a telephone number, if the From header is, for example, an e-mail address. Using this new header, let us call is Also-From, a proxy (or the calling endpoint itself) may also insert a telephone number, which can then be used by PSTN Gateways for any kind of A-number analysing. One could argue that the caller should always include a telephone number in the From header, but the caller may not know that the call will end up on the PSTN side, so... I DO like the Diversion draft very much, though, but it doesn't solve this specific problem :) Regards, Christer Holmberg Ericsson Finland Bryan Byerly wrote: >=20 > Hi guys, >=20 > What do you guys think about using the Diversion header > (http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-00.txt) = instead of > Also-From? > It seems like a natural replacement to me. >=20 > Thanks! > Bryan >=20 > Christer Holmberg wrote: >=20 > > Hi, > > > > This is something I've also been looking into. > > > > One way would be to add a new header (e.g. Also-From). That header = could > > be inserted by a proxy that does know the request may end up in a > > gateway. The UA may not know that, so he could put whatever string = in > > the user part of the From header (e.g. his e-mail address). If the = proxy > > then knows the UAs telephone number, for example by using some kind = of > > database lookup, which is needed by the gateway - for any possible > > A-number procedure - the proxy can add that to the request. > > > > Another way would be to just define a URI parameter for the From = header, > > but the bad thing about that is that it can not be inserted by a = proxy > > if it was not in the request from the UA (since the From header must = not > > be changed) by a proxy, or any other intermediate node. > > > > Note, that this response is according to Clive's mail. I do NOT = support > > the idea of ALSO-TO headers, multiple FROM/TO headers and whatever = was > > proposed in the previous mails :) > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > clive.dellard@bt.com wrote: > > > > > > I agree with what you say, however, if you consider a call = originating from > > > a SIP device (telephone or softphone) that ends up going through a = gateway > > > to the PSTN then it is a different story. > > > Neither the user or the UAC can know where a call will end up, = therefore the > > > ability to be able to provide both SIP address and SIP Telephone = number > > > would be useful to providing a complete service as then an = appropriate > > > calling address is available wherever the call ends up. In the = scenario I > > > described the gateway could chose the Telephone number (ok I know = there are > > > verification issues but that's another story). > > > Something like Simon's idea of an "ALSO-FROM" seems a good idea to = me (this > > > is similar to "two number delivery" in the ISDN CLIP service) = older versions > > > would just ignore the ALSO-FROM and it wouldn't affect the = significance of > > > the FROM and TO headers. > > > > > > Clive > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > > > > Sent: Wednesday, October 11, 2000 7:41 PM > > > > To: 'clive.dellard@bt.com'; 'sip@lists.bell-labs.com' > > > > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > > > > > Sent: Wednesday, October 11, 2000 12:17 PM > > > > > To: sip@lists.bell-labs.com > > > > > Subject: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > In the call flows document draft-ietf-sip-call-flows-01.txt, > > > > > scenario 4.1.1, > > > > > the message detail and text show User A using a SIP telephone > > > > > number rather > > > > > than a SIP address in the From header. The text at the > > > > > beginning of section > > > > > 4 also says "that User A still uses his/her SIP URL in the > > > > > Contact header, > > > > > since the call could be redirected back to the SIP network." > > > > > This implies that User A has pre-knowledge that the call is > > > > > going to route > > > > > to the PSTN and has the ability to chose the address to be > > > > > used in the From > > > > > header. > > > > > > > > No. > > > > > > > > The From header is the logical identity of the user making the = call. Since > > > > the call is coming through a gateway, that user is some user on = a PSTN > > > > terminal somewhere. The identity in this case can either be a = tel URL, or > > > > a > > > > SIP URL at the domain of the originating network. > > > > > > > > The Contact is used for signaling addressing. Its not a logical > > > > identifier. > > > > It answers the question "where should I send SIP messages to for = the rest > > > > of > > > > this call". The SIP spec says this is supposed to be a SIP URL = preferably > > > > with a complete hostname, so that there are no ambiguities about = where to > > > > send requests. > > > > > > > > Neither of these have anything to do with knowing where the call = is going. > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ = 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) = 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) = 952-5000 > > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_0194_01C04E65.4E7619C0 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0194_01C04E65.4E7619C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:34: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 EAA26911 for ; Tue, 14 Nov 2000 04:34:44 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B2BDD44383; Tue, 14 Nov 2000 03:08:41 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 08A2644336 for ; Tue, 14 Nov 2000 03:05:22 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91VJ03573; Tue, 14 Nov 2000 18:01:31 +0900 Message-ID: <033f01c04e1a$0413da20$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Steve Donovan" , "hammer michael" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01B4_01C04E65.50EAC340" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:31 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C04E65.50EAC340 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >>>Thus you are in support of not trying to implicitly use a method >>>to do what a subordinate capability should be explicitly defined to = do? >> >>I didn't say that. Of course it is nice if we can >>get-two-things-by-doing-one, but in this case I just see some issues. >>Again, first there is the thing that by using re-INVITEs we will >>generate ACKs. >> >>Second, which I think is related to your mail, is when the UAS boots, >>and the re-INVITE is seen as a new INVITE to establish a new session. = We >>may get 18x responses before the final response, and the final = response >>can be a 3xx, 4xx, 5xx or 6xx response, and in some cases it may be = very >>difficult for the UAC to behave in a good way. If we use INFO, and >>receive 481, the UAS knows that the session doesn't exist anymore, and >>can do whatever is needed, and then, if wanted, send a new INVITE to >>re-establish the call. It gives the UAC more control, and the UAC may, >>for some reason, even want to know if a session died. >I don't believe this is the scenario that is addressed by the goal of = >being able to re-establish the session. Remember that the entity = >managing the SIP session information and the entity participating in = the >RTP session do not need to be the same machine. So the scenario is = that >the SIP UAS has lost track of the SIP state related of an RTP = session, >but the RTP session is still active. The re-INVITE would = allow the SIP >UAS to re-establish SIP state for the session without a = new call being >set up. In this scenario, it would not send 18x, 3xx, = 4xx, 5xx or 6xx >responses. Maybe not in this specific scenario, but it MAY happen depending of the architecture and logic of the remote party. I would like the heartbeat mechanism, and the logic to support it, to be as simple as possible, i.e. you send a request and receive a response. Then, depending on the response, the UAC can choose to do whatever he wishes to. In some systems, for example, he may choose to use another UAS, or whatever, if the session has died. =20 >While it is true that there are other ways that this could have been = >solved, it is pretty late in the game to make this kind of a change. = >Especially if the only reason for doing so is to avoid the ACK message. Well, as has been discussed here, that is not the only reason, but I still think it is a good reason. >As a side note, we are in the process of creating a new version of the = >draft that we hope will be used for working group last call. One option, which has been proposed, was to define a new functionality, "session ping", e.g. by using the INFO method extension.=20 Regards, Christer Holmberg Ericsson Finland >=20 > Steve ------=_NextPart_000_01B4_01C04E65.50EAC340 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_01B4_01C04E65.50EAC340-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:37: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 EAA27806 for ; Tue, 14 Nov 2000 04:37:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 35B0744367; Tue, 14 Nov 2000 03:07:45 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 48BB54433F for ; Tue, 14 Nov 2000 03:05:13 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91MJ03521; Tue, 14 Nov 2000 18:01:22 +0900 Message-ID: <02fc01c04e19$fee763a0$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "hammer michael" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01C04E65.4E5DAFC0" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:22 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_018C_01C04E65.4E5DAFC0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >Thus you are in support of not trying to implicitly use a method to do = >what a subordinate capability should be explicitly defined to do? I didn't say that. Of course it is nice if we can get-two-things-by-doing-one, but in this case I just see some issues. Again, first there is the thing that by using re-INVITEs we will generate ACKs.=20 Second, which I think is related to your mail, is when the UAS boots, and the re-INVITE is seen as a new INVITE to establish a new session. We may get 18x responses before the final response, and the final response can be a 3xx, 4xx, 5xx or 6xx response, and in some cases it may be very difficult for the UAC to behave in a good way. If we use INFO, and receive 481, the UAS knows that the session doesn't exist anymore, and can do whatever is needed, and then, if wanted, send a new INVITE to re-establish the call. It gives the UAC more control, and the UAC may, for some reason, even want to know if a session died. Regards, Christer Holmberg Ericsson Finland >=20 > Mike >=20 > At 05:00 PM 10/17/2000 +0300, Christer Holmberg wrote: >=20 > >Hi, > > > >If I send you an INFO, or any other method that you don't support, = you > >can for example send a 501 Not Implemented response, and include an > >Allow header with the methods you support. Of course, you can't stop = the > >UAC of sending the method again, if he chooses to... > > > >You can not, however, tell an UAC not to send you re-INVITEs, because > >then you would also forbid the UAC to send you INVITEs - and I don't > >think you want to do that. Also, the specification says that a UA = MUST > >be able to receive INVITEs (which included re-INVITEs), so... > > > >Regards, > > > >Christer Holmberg > >Ericsson Finland > > > > > >hammer michael wrote: > > > > > > Is this the Internet version of "let them eat cake?" Signal-spam = is not > > > more palatable than the normal variety. > > > > > > Is there a response code that can indicate the sentiment: I don't = support > > > this method, don't try it again? It might also be good to make = sure that > > > such undesirable sub-methods are indicated as "Unsupported." If = that > > > sub-method is well-defined, then that header parameter should be > > applicable. > > > > > > Mike > > > > > > At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote: > > > > > > >Hi, > > > > > > > > >Good points. Here's one more problem you may want to consider. > > > > >Whenever you invoke a ping-style method of deciding if a = session is > > > > >alive, you open up problems due to network jitter and = bandwidth. For > > > > >instance, you could easily have a packet delayed at an endpoint = due to > > > > >a large file transfer starting up, or some other bandwidth = consuming > > > > >event. In this case, your ping could be delayed long enough to = cause > > > > >the session to drop for no good reason. > > > > > > > >Well, this could be the case no matter which method (INVITE, = INFO, or > > > >whatever...) you use in the heartbeat request... > > > > > > > > >You're also creating the potential for artificial problems in = wireless > > > > >networks by using a ping-method to keep a session alive. During = a > > > > >handover there may be a period where packets are in effect = "muted" for > > > > >a short period of time. The mute period may not, by itself be = long > > > > >enough to trigger a ping-timer to pop and kill the session, but = if the > > > > >ping was near the edge of the time envelope to be accepted as > > > > >"on-time" anyhow, once again, your session could very easily = drop when > > > > >the media was operating just fine. > > > > >Also, keep in mind, the longer you set the ping timer for, the = more > > > > >network resources you will likely waste over time because of = the > > > > >additional latentcy in discovering a "dead" session. > > > > > > > >Just to clarify, this "ping-method" IS already defined for SIP > > > >(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to = ping. > > > >My idea was about replacing the re-INVITE with INFO, which mean = we would > > > >actually save resources since we don't have to send ACK every = time. > > > > > > > > >This method has one other nasty side-effect. You'd be wasting = network > > > > >resources on an event that will likely not occur very often. = After > > > > >all, every INFO exchange except the very last one that = invalidates the > > > > >session could have very well not been sent without any negative = impact > > > > >on the session (otherwise they would have been the last one). = So > > > > >you've got proxies and UAs, and other transport resources being = tied > > > > >up processing packets that by and large are providing no value, = and > > > > >they're chewing up bandwidth budget that other services could = be using > > > > >instead. > > > > > > > >That is an interesting point, and it is valid also for a number = of other > > > >SIP extensions where extra messages are sent (e.g. PRACK), but it = is > > > >another discussion. > > > > > > > > >Please keep in mind that not everyone is looking at = implementing SIP > > > > >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous = numbers > > > > >of users), pinging and triangle-routing can be the death-knell = of > > > > >these sorts of networks. > > > > > > > >Who said "bandwidth is free"? :) > > > > > > > > >Because of all of this, I think it would be a very bad idea for = a UA > > > > >to send an INFO to a client who repeatedly tells him "I don't > > > > >understand INFO" to see if he's alive. > > > > > > > >The number of messages on the network will be the same no matter = if we > > > >send an INVITE which he understands, or an INFO he may not = understand. > > > >Also, when we receive the response for the INVITE we also have to = send > > > >back an ACK, which is not the case when INFO is used. > > > > > > > > >He may not understand INFO because that particular network = doesn't > > > > deem >the bandwidth required for this mechanism as being best = used for > > > > that >purpose. If someone tells you "don't send me this method" = then > > > > don't send >it to them. > > > > > > > >Again, this has nothing to do with the bandwith issue. Even if I = send > > > >re-INVITEs, which the other party understands, he can not tell me = not to > > > >send any more re-INVITEs. > > > > > > > > >Otherwise your implementation may be viewed as favorably as the = record > > > > >clubs that used to require you to send them a card every month = telling > > > > >them not to send you anything by some groups. > > > > > > > >Well, it's not up to me to decide when and if an operator will = use the > > > >session-timer, as defined in the draft, or not - I am just trying = to > > > >make it as good (and less resource consuming) if he choses to. > > > > > > > >Regards, > > > > > > > >Christer Holmberg > > > >Ericsson Finland > > > > > > > > > > > > > > > > > > Brian Stucker > > > > > Nortel Networks > > > > > > > > > > -----Original Message----- > > > > > From: Culpepper, Bert = [mailto:bert.culpepper@intervoice-brite.com] > > > > > Sent: Monday, October 16, 2000 3:38 PM > > > > > To: Christer Holmberg; sip@lists.bell-labs.com > > > > > Cc: Rohan Mahy > > > > > Subject: RE: [SIP] Session-timer with INFO > > > > > > > > > > Some things to think about. > > > > > > > > > > I believe INFO is _not_ to be used to modify the state of a = session. > > > > > I > > > > > suppose a debate is possible about session-timer affecting = session > > > > > state - present vs. future and if INFO is only restricted to = one. But > > > > > it's > > > > > probably best to leave it alone. Also, the INV-200-ACK = exchange > > > > > allows multiple parties to agree on the duration of the = session. If > > > > > the > > > > > recipient of the INFO request wants a smaller value (because = its > > > > > heartbeat interval is shorter) for the session timer it would = have to > > > > > send its own INFO request (unless you plan to keep the = proposed > > > > > Session-expires header and its use in a 200 OK). Now four > > > > > messages are needed. In addition, there may be proxy issues = when > > > > > using INFO. There's other behavior described in the draft = too. > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg = [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > Sent: Monday, October 16, 2000 3:42 PM > > > > > > To: sip@lists.bell-labs.com > > > > > > Cc: Rohan Mahy > > > > > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Thanks for the comments! > > > > > > > > > > > > >If the UA crashed and rebooted and forgot about the old = session, it > > > > > > > > > > > would > > > > > > >respond with either a 481 call leg doesn't exist (you would = know > > > > > the > > > > > > call > > > > > > >is down), or a 501 (you know the UA is up, but is the = call?) > > > > > > > > > > > > > >thanks, > > > > > > >-rohan > > > > > > > > > > > > I think that would be good, because then we could inform the = user > > > > > that > > > > > > the call doesn't exist anymore. > > > > > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > > > session-timer re-INVITE. If the UAS has forgotten about the = old > > > > > > session > > > > > > it would consider the re-INVITE as a new INVITE, for a new = session. > > > > > It > > > > > > would try to establish a new session - and we could suddenly = start > > > > > > receiving provisional 18x responses (with or without SDP = bodies), > > > > > > and/or > > > > > > a 200 response with a SDP body, to the session-timer = re-INVITE. What > > > > > > > > > > > do > > > > > > we do then? > > > > > > > > > > Well, you could ignore the provisional responses (you know the = other > > > > > end > > > > > is confused) and let the session get re-established or decide = to > > > > > terminate > > > > > the session with CANCEL/BYE. > > > > > > > > > > Regards, > > > > > Bert > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would = just > > > > > like > > > > > > to > > > > > > > >hear some opinions - or maybe it has already been = discussed on > > > > > the > > > > > > list? > > > > > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a = message > > > > > > > > > > > body, > > > > > > > >a server supporting INFO MUST respond with response code = 200. So, > > > > > > > > > > > my > > > > > > > >question is: why couldn't INFO be used for the = session-timer > > > > > > > >functionality? Is the ACK the (re-)INVITE provides really > > > > > necessary > > > > > > for > > > > > > > >the purpose? > > > > > > > > > > > > > > > >And, like the session-timer is defined now, the other = party would > > > > > > > > > > > not > > > > > > > >even have to support the INFO method, because a 501 Not > > > > > Implemented > > > > > > > >would be sent, and the sender of the INFO would know the = session > > > > > is > > > > > > > >"alive". > > > > > > > > > > > > > > > >Just some thoughts... Please let me know if there is = something I > > > > > > haven't > > > > > > > >taken into consideration. > > > > > > > > > > > > > > > >Regards, > > > > > > > > > > > > > > > >Christer Holmberg > > > > > > > >Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_018C_01C04E65.4E5DAFC0 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_018C_01C04E65.4E5DAFC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:40: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 EAA28722 for ; Tue, 14 Nov 2000 04:40:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 35FA14438A; Tue, 14 Nov 2000 03:08:52 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 714A044339 for ; Tue, 14 Nov 2000 03:05:29 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91cJ03597; Tue, 14 Nov 2000 18:01:38 +0900 Message-ID: <037101c04e1a$08661d40$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Jonathan Rosenberg" , "Bryan Byerly" , , Subject: Re: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BD_01C04E65.512645A0" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:38 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_01BD_01C04E65.512645A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >>>A follow-up question: >>>How does/does Also-From header differ from the Remote-Party-Id header >>>(draft-dcsgroup-sip-privacy-02.txt)? >> >>Well, it could perhaps be possible to use that header, but the whole >>concept of that draft is a little different than just adding an >>telephone number alias to the caller, and by supporting it I guess you >>would have to do more implementation than necessary for this specfic >>need. Also, depending on what is put in Remote-Party-Id header, it is >>not even sure it would solve the problem. > >I agree. Remote-Party-ID is supposed to be an address that the network = >has "verified" to be the actual address of the originator. It is even = >stripped if verification cannot take place. THis seems a bit at odds = with >the desired function here. >=20 >That said, I still do not understand this need for YAI (yet another >identifier). This previous motivation involving the termination in the = >PSTN or IP network is totally bogus. At this point, I am very, very, = very >reluctant to add new stuff without serious justification. I agree, that this is simply an alias for the From header value, it is maybe not such a good, and efficient, way to add a new header. Another way would be to simply add a "telephone-number" URI parameter. In that case, however, the UAC must insert it (since intermediate nodes are not allowed to change to From header). Another way would be for the UAS (the PSTN GW in this case) to send a response, asking for the telephone number. A new INVITE, with the telephone number in the From (in some cases the URI could even be changed from a SIP-URL to a TEL-URL) header. And, if the "telephone-number" URI parameter is used, the From URI would not have to be changed in the new INVITE - the parameter would simply be added to the old SIP-URL. Regards, Christer Holmberg Ericsson Finland =20 > -Jonathan R. >=20 > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com ------=_NextPart_000_01BD_01C04E65.512645A0 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_01BD_01C04E65.512645A0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:54: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 EAA03142 for ; Tue, 14 Nov 2000 04:54:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D29FE443A3; Tue, 14 Nov 2000 03:09:36 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 9600344336 for ; Tue, 14 Nov 2000 03:05:48 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91vJ03713; Tue, 14 Nov 2000 18:01:57 +0900 Message-ID: <03db01c04e1a$13c27080$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Brian Stucker" , "hammer michael" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0223_01C04E65.585988A0" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:57 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0223_01C04E65.585988A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, I think this issue is also related to another thread, 'Source Routing/Route out of band'. If the reason for using re-INVITE is that booted stateful proxies can re-establish the session, but they don't support Routes in a new INVITE, I guess it will not work. Of course, an INFO would not pass that proxy either, so it is a general problem, and does not only affect the session-timer functionality. Christer Holmberg Ericsson Finland > Brian Stucker wrote: > > Your correct, I can't stop the UAC from sending the method again, but > I'd like to plead to as many implementors as I can that it would > definitely be preferable in any setting if you wouldn't. =) > > Brian > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, October 17, 2000 9:00 AM > To: sip@lists.bell-labs.com > Cc: hammer michael > Subject: Re: [SIP] Session-timer with INFO > > Hi, > > If I send you an INFO, or any other method that you don't support, you > > can for example send a 501 Not Implemented response, and include an > Allow header with the methods you support. Of course, you can't stop > the > UAC of sending the method again, if he chooses to... > > You can not, however, tell an UAC not to send you re-INVITEs, because > then you would also forbid the UAC to send you INVITEs - and I don't > think you want to do that. Also, the specification says that a UA MUST > > be able to receive INVITEs (which included re-INVITEs), so... > > Regards, > > Christer Holmberg > Ericsson Finland > > hammer michael wrote: > > > > Is this the Internet version of "let them eat cake?" Signal-spam is > not > > more palatable than the normal variety. > > > > Is there a response code that can indicate the sentiment: I don't > support > > this method, don't try it again? It might also be good to make sure > that > > such undesirable sub-methods are indicated as "Unsupported." If > that > > sub-method is well-defined, then that header parameter should be > applicable. > > > > Mike > > > > At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote: > > > > >Hi, > > > > > > >Good points. Here's one more problem you may want to consider. > > > >Whenever you invoke a ping-style method of deciding if a session > is > > > >alive, you open up problems due to network jitter and bandwidth. > For > > > >instance, you could easily have a packet delayed at an endpoint > due to > > > >a large file transfer starting up, or some other bandwidth > consuming > > > >event. In this case, your ping could be delayed long enough to > cause > > > >the session to drop for no good reason. > > > > > >Well, this could be the case no matter which method (INVITE, INFO, > or > > >whatever...) you use in the heartbeat request... > > > > > > >You're also creating the potential for artificial problems in > wireless > > > >networks by using a ping-method to keep a session alive. During a > > > > >handover there may be a period where packets are in effect > "muted" for > > > >a short period of time. The mute period may not, by itself be > long > > > >enough to trigger a ping-timer to pop and kill the session, but > if the > > > >ping was near the edge of the time envelope to be accepted as > > > >"on-time" anyhow, once again, your session could very easily drop > when > > > >the media was operating just fine. > > > >Also, keep in mind, the longer you set the ping timer for, the > more > > > >network resources you will likely waste over time because of the > > > >additional latentcy in discovering a "dead" session. > > > > > >Just to clarify, this "ping-method" IS already defined for SIP > > >(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to > ping. > > >My idea was about replacing the re-INVITE with INFO, which mean we > would > > >actually save resources since we don't have to send ACK every time. > > > > > > > >This method has one other nasty side-effect. You'd be wasting > network > > > >resources on an event that will likely not occur very often. > After > > > >all, every INFO exchange except the very last one that > invalidates the > > > >session could have very well not been sent without any negative > impact > > > >on the session (otherwise they would have been the last one). So > > > >you've got proxies and UAs, and other transport resources being > tied > > > >up processing packets that by and large are providing no value, > and > > > >they're chewing up bandwidth budget that other services could be > using > > > >instead. > > > > > >That is an interesting point, and it is valid also for a number of > other > > >SIP extensions where extra messages are sent (e.g. PRACK), but it > is > > >another discussion. > > > > > > >Please keep in mind that not everyone is looking at implementing > SIP > > > >on a 10Mbit+ hardwired LAN (or has to scale up to tremendous > numbers > > > >of users), pinging and triangle-routing can be the death-knell of > > > > >these sorts of networks. > > > > > >Who said "bandwidth is free"? :) > > > > > > >Because of all of this, I think it would be a very bad idea for a > UA > > > >to send an INFO to a client who repeatedly tells him "I don't > > > >understand INFO" to see if he's alive. > > > > > >The number of messages on the network will be the same no matter if > we > > >send an INVITE which he understands, or an INFO he may not > understand. > > >Also, when we receive the response for the INVITE we also have to > send > > >back an ACK, which is not the case when INFO is used. > > > > > > >He may not understand INFO because that particular network > doesn't > > > deem >the bandwidth required for this mechanism as being best used > for > > > that >purpose. If someone tells you "don't send me this method" > then > > > don't send >it to them. > > > > > >Again, this has nothing to do with the bandwith issue. Even if I > send > > >re-INVITEs, which the other party understands, he can not tell me > not to > > >send any more re-INVITEs. > > > > > > >Otherwise your implementation may be viewed as favorably as the > record > > > >clubs that used to require you to send them a card every month > telling > > > >them not to send you anything by some groups. > > > > > >Well, it's not up to me to decide when and if an operator will use > the > > >session-timer, as defined in the draft, or not - I am just trying > to > > >make it as good (and less resource consuming) if he choses to. > > > > > >Regards, > > > > > >Christer Holmberg > > >Ericsson Finland > > > > > > > > > > > > > > Brian Stucker > > > > Nortel Networks > > > > > > > > -----Original Message----- > > > > From: Culpepper, Bert > [mailto:bert.culpepper@intervoice-brite.com] > > > > Sent: Monday, October 16, 2000 3:38 PM > > > > To: Christer Holmberg; sip@lists.bell-labs.com > > > > Cc: Rohan Mahy > > > > Subject: RE: [SIP] Session-timer with INFO > > > > > > > > Some things to think about. > > > > > > > > I believe INFO is _not_ to be used to modify the state of a > session. > > > > I > > > > suppose a debate is possible about session-timer affecting > session > > > > state - present vs. future and if INFO is only restricted to > one. But > > > > it's > > > > probably best to leave it alone. Also, the INV-200-ACK exchange > > > > > allows multiple parties to agree on the duration of the > session. If > > > > the > > > > recipient of the INFO request wants a smaller value (because its > > > > > heartbeat interval is shorter) for the session timer it would > have to > > > > send its own INFO request (unless you plan to keep the proposed > > > > Session-expires header and its use in a 200 OK). Now four > > > > messages are needed. In addition, there may be proxy issues > when > > > > using INFO. There's other behavior described in the draft too. > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Monday, October 16, 2000 3:42 PM > > > > > To: sip@lists.bell-labs.com > > > > > Cc: Rohan Mahy > > > > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Thanks for the comments! > > > > > > > > > > >If the UA crashed and rebooted and forgot about the old > session, it > > > > > > > > > would > > > > > >respond with either a 481 call leg doesn't exist (you would > know > > > > the > > > > > call > > > > > >is down), or a 501 (you know the UA is up, but is the call?) > > > > > > > > > > > >thanks, > > > > > >-rohan > > > > > > > > > > I think that would be good, because then we could inform the > user > > > > that > > > > > the call doesn't exist anymore. > > > > > > > > > > Let's assume the UAS crashes, reboots and the UAC sends the > > > > > session-timer re-INVITE. If the UAS has forgotten about the > old > > > > > session > > > > > it would consider the re-INVITE as a new INVITE, for a new > session. > > > > It > > > > > would try to establish a new session - and we could suddenly > start > > > > > receiving provisional 18x responses (with or without SDP > bodies), > > > > > and/or > > > > > a 200 response with a SDP body, to the session-timer > re-INVITE. What > > > > > > > > > do > > > > > we do then? > > > > > > > > Well, you could ignore the provisional responses (you know the > other > > > > end > > > > is confused) and let the session get re-established or decide to > > > > > terminate > > > > the session with CANCEL/BYE. > > > > > > > > Regards, > > > > Bert > > > > > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:55 AM 10/16/00 , Christer Holmberg wrote: > > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >First, this mail is NOT a proposal for a change. I would > just > > > > like > > > > > to > > > > > > >hear some opinions - or maybe it has already been discussed > on > > > > the > > > > > list? > > > > > > > > > > > > > >The INFO Method RFC says that for INFO requests without a > message > > > > > > > > > body, > > > > > > >a server supporting INFO MUST respond with response code > 200. So, > > > > > > > > > my > > > > > > >question is: why couldn't INFO be used for the > session-timer > > > > > > >functionality? Is the ACK the (re-)INVITE provides really > > > > necessary > > > > > for > > > > > > >the purpose? > > > > > > > > > > > > > >And, like the session-timer is defined now, the other party > would > > > > > > > > > not > > > > > > >even have to support the INFO method, because a 501 Not > > > > Implemented > > > > > > >would be sent, and the sender of the INFO would know the > session > > > > is > > > > > > >"alive". > > > > > > > > > > > > > >Just some thoughts... Please let me know if there is > something I > > > > > haven't > > > > > > >taken into consideration. > > > > > > > > > > > > > >Regards, > > > > > > > > > > > > > >Christer Holmberg > > > > > > >Ericsson Finland > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_0223_01C04E65.585988A0 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0223_01C04E65.585988A0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 04:57: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 EAA04287 for ; Tue, 14 Nov 2000 04:57:36 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5D5D443A8; Tue, 14 Nov 2000 03:09:47 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id DB0BA44339 for ; Tue, 14 Nov 2000 03:05:51 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91eJ03626; Tue, 14 Nov 2000 18:01:40 +0900 Message-ID: <038001c04e1a$0a115c40$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: , , Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01DD_01C04E65.54F9E2E0" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:40 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_01DD_01C04E65.54F9E2E0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Greetings Chris: Just to add a pointer to this thread: Maintaining trasaction state is an application level functionality and *shouldn't* be implemented in the base stack. For applications like state oriented proxy server, the JAIN SIP can provide enough hooks for event delivery but the state has to be maintained by the proxy server. Pleas keep up the good work. It is really appreciated. Regards, Bobby.Sardana@mobilerain.com Chris Harris wrote: > "M. Ranganathan" wrote: > >> Hi Chris, >> >> Thanks for replying so promptly (I am sure you are flooded with >> email ). > > I get one or two :) > >> >> As you pointed out, I suppose we cannot do away with making Messages >> >> into classes because of the tie-in with java events (unfortunately) >> but >> I still like the notion of being able to specify interfaces where >> ever >> possible. > > I see where you're coming from alright, and I suppose changing header > classes into interfaces, could fit in with Gethin's proposal nicely? > >> >> I dont quite follow the motivation behind the following design >> decision (excerpted from your reply): >> >> Maybe I've misunderstood what you're saying - but a JAIN SIP >> implementation is only stateless when it comes to call state. The >> JainSipProvider implementation must maintain transaction state - it >> simply exposes a reference to a transaction via the transaction id >> for >> the convenience of the JainSipListener. The service does not have >> total >> control over transacton state - the stack implementation does. >> >> It appears that I have indded mis-understood the architecture. Why >> should the above be so? Can one not rely on the JainSipListener to >> keep >> transaction state also, thereby making the stack simply a way of >> recognising messages and triggering event handlers on the basis of >> message type. This would (IMHO) be a cleaner model yet. That >> way, we >> can do away with transaction identifiers being passed back and forth >> and >> keep all of this information in the handler. ( You may have to >> extend >> the architecture somewhat to deal with timeouts and failures so that >> the >> handler knows about transaction failure.) In any case, if this is >> not a >> viable idea, I would be grateful if you can explain why not (or >> point me >> to the portion of the spec that explains why not) so I can get a >> better >> understanding. > > It would be cleaner model, and personally I am in total agreement with > you - but it means the application is forced to maintain transaction > state, match up headers - which has been said places too much of a > burden on applications. How about finding a way to let the application > choose whether or not it wants to keep transaction state? > >> >> >> Regards, >> >> Ranga. >> >> Chris Harris wrote: >> >> > Hi Ranga, >> > >> > Response below... >> > >> > Chris >> > >> > "M. Ranganathan" wrote: >> > >> >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many >> >> >> thanks to Chris and >> >> the JAIN-SIP team for putting together a spec and more flower >> power >> >> to them :-) . In >> >> particular I like the notion of treating UAS, Redirect and Proxy >> >> >> servers as merely >> >> special cases of the general notion of Services and the idea of >> >> unifying these >> >> notions with an event mechanism and event handlers. Second, I >> like >> >> the idea of >> >> separation between a stateless event -oriented "stack" and a >> bunch >> >> of event >> >> handlers that are triggered by the stack with all state >> (including >> >> transaction >> >> state) being separated from the event stack via the JAIN-SIP >> mapping >> >> layer if you >> >> will. ( Correct me if I wax poetic but have the wrong >> >> understanding....) >> > >> >> >> >> >> >> I hope I will not be viewed as being too critical, but I would >> >> like to go one step >> >> further than what Gethin is suggesting. I am all for using >> >> interfaces as much as >> >> possible and leaving class hierarchy definitions to implemeters. >> >> Defining class >> >> hierarchies almost lays out an implementation and involves >> >> considerable rework for >> >> those who have a working java-based stack, but have not used the >> >> same classes. OK it >> >> is just a matter of labor to map things to the JAIN-SIP class >> >> hierarchy but it IS a >> >> dis-incentive. >> >> >> >> 1. Lets use interfaces for all messages rather than actually >> define >> >> class >> >> hierarchies ( yes Chris has pointed out the historical precedent >> >> >> behind actually >> >> defining class hierarchies for messages. IMHO, there has to be a >> >> >> more compelling >> >> reason than that.) >> > >> > I suppose all classes could be turned into interfaces, except for >> the >> > Message classes which must extend java.util.EventObject to fit >> into >> > the JAIN framework. >> > >> >> >> >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated the >> >> explicit definition >> >> of class hierarchies in certain places. Why not use callbacks >> >> instead and do away >> >> with this dependency as well? (Basically the same thing as >> events >> >> but does not tie >> >> into the JAVA event mechanism and its associated limitations.) >> > >> > Unfortunately the JAIN framework expilicitly relies on the Java >> Event >> > model, and I don't think callbacks would be accepted within the >> JAIN >> > community. >> > >> >> >> >> >> >> Nice work and keep it rolling! Thanks. >> > >> > Couldn't do it without you guys - thank you! >> > >> >> >> >> >> >> Ranga. >> >> >> >> Gethin Liddell wrote: >> >> >> >> > All, >> >> > >> >> > This idea of abstraction of the JAIN API is certainly a valid >> and >> >> > interesting idea. However, i'm a bit concerened that the >> proposed >> >> >> >> > solution of many different packages, will only seek to >> complicate >> >> and >> >> > maybe enlarge the API. >> >> > >> >> > I too see no reason why there is an EntityHeader etc... and i >> also >> >> do >> >> > not see any requirement for an InviteMessage, AckMessage etc... >> >> >> > >> >> > How about if the format of the API remains as is: >> >> > >> >> > jain.protocol.ip.sip >> >> > jain.protocol.ip.sip.header >> >> > jain.protocol.ip.sip.message >> >> > >> >> > except that the messages available in the message package >> >> consisted of >> >> > BasicRequest/Response, MinimalRequest/Response etc... where >> each >> >> > message is extened in turn (e.g. Minimal extends Basic, >> Moderate >> >> > extends Minimal etc...), of course as Chris points out it is >> not >> >> hard >> >> > to see that a combination would be required that is not >> provided. >> >> So >> >> > in the interest of flexibility, it could be possible for the >> user >> >> to >> >> > plug-in to the message class what extra headers it requires. >> The >> >> only >> >> > issue then is that the user will have to use a "public Header >> >> > getHeader(String headerName)" and then cast the header to their >> >> >> desired >> >> > header type. Either that or create their own Message class >> >> > (extending the current ones) that simply does the casting >> >> automatically >> >> > for them. Then after compiling, run an obfuscator on the code >> and >> >> it >> >> > will automatically extract and only extract the Message, >> Headers >> >> and >> >> > even methods that are used. >> >> > >> >> > This then will also cut down on the number of methods in the >> >> Provider >> >> > as there will be no need for the sendAck(AckMessage), >> >> > sendInvite(InviteMessage) etc.. as they would be replaced by >> the >> >> > single method sendRequest(RequestMessage). >> >> > >> >> > I personally see three arguments for keeping the JAIN SIP stack >> as >> >> small >> >> > as possible: >> >> > >> >> > 1) The first is for embedded applications where stack size has >> to >> >> be >> >> > kept to a minimum as memory is at a premium. So if just using >> the >> >> >> >> > Basic message suffices then this will compile and run with a >> small >> >> >> >> > number of classes present from the stack. Don't forget, >> >> obfuscation >> >> > will help in extracting only the Messages, Headers and even >> >> methods >> >> > required from a jar file but it won't do everything. >> >> > >> >> > 2) The second is that users may be put off or confused by the >> >> sheer >> >> > size and complexity of the JAIN stack. So if only using the >> >> > BasicMessage gets them on the first rung of the ladder then it >> is >> >> a >> >> > good starting point and allows them to build up to bigger and >> >> better >> >> > things. >> >> > >> >> > 3) We also have to consider who is going to implement the JAIN >> SIP >> >> >> >> > stack. If it is indeed overly complicated then no-one or a >> single >> >> > vendor may end up implmenting the stack and thus its definition >> >> >> and >> >> > all the hard work that has gone into it is useless. >> >> > >> >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> >> > > Itamar, >> >> > > >> >> > > The idea of levelling the API based on what messages, headers >> >> >> and response codes >> >> > > are understood is certainly an interesting one - minimal, >> basic, >> >> redirection, >> >> > > firewall-friendly, negotiation, authentication and "full". >> >> > > >> >> > > jain.protocol.ip.sip >> >> > > jain.protocol.ip.sip.header >> >> > > jain.protocol.ip.sip.message >> >> > > >> >> > > could then become... >> >> > > >> >> > > jain.protocol.ip.sip - listener, provider, stack, general >> >> classes used at all >> >> > > levels >> >> > > jain.protocol.ip.sip.header - contains base Header class (and >> >> >> requestHeader, >> >> > > ResponseHeader, EntityHeader, GeneralHeader) >> >> > > jain.protocol.ip.sip.message - contains base Message class >> >> > > >> >> > > jain.protocol.ip.sip.minimal - general classes used only at >> this >> >> level and above >> >> > > >> >> > > jain.protocol.ip.sip.minimal.header - headers used only at >> this >> >> level and above >> >> > > jain.protocol.ip.sip.minimal.message - messages only used at >> >> this level and >> >> > > above >> >> > > >> >> > > jain.protocol.ip.sip.basic - general classes used only at >> this >> >> level and above >> >> > > jain.protocol.ip.sip.basic.header - headers used only at this >> >> >> level and above >> >> > > jain.protocol.ip.sip.basic.message - messages used only at >> this >> >> level and above >> >> > > ... >> >> > > .... >> >> > > jjain.protocol.ip.sip."full" - general classes only used at >> this >> >> level >> >> > > jain.protocol.ip.sip."full".header - headers used only at >> this >> >> level >> >> > > jain.protocol.ip.sip."full".message - messages used only at >> this >> >> level >> >> > > >> >> > > The API user could then pick the packages they need - say >> they >> >> initially only >> >> > > want the minimal features, but then realise they need to use >> >> their application >> >> > > behind a firewall - then they can simply add the >> >> firewall-friendly package. The >> >> > > RFC says "In general, each capability listed builds on the >> ones >> >> above it" but it >> >> > > is not hard to see that firewall-friendly and authentication >> may >> >> be desired >> >> > > without redirection for example. >> >> > > >> >> > > Is this what you hand in mind Itamar? >> >> > >> >> > -- >> >> > Gethin Liddell >> >> > Ubiquity Software Corporation >> >> > >> >> > http://www.ubiquity.net >> >> > mailto:gethin@ubiquity.net >> >> > >> >> > _______________________________________________ >> >> > SIP mailing list >> >> > SIP@lists.bell-labs.com >> >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> >> >> -- >> >> M.Ranganathan >> >> NIST Advanced Networking Technologies Group, >> >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> >> >> Hf=E6j)b? = b=B2=D4^>X=AC=B6=C6=DE-YZn=C7(s=1Bm=A7=FF=E5S=CBlm=E9e*=A6=ECr?=BF?=A8=A5= ?=A9=FF-+-Sw=E8=FE=C8=A9 >> > >> >> -- >> M.Ranganathan >> NIST Advanced Networking Technologies Group, >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> Hf=E6j)b? = b=B2=D4^>X=AC=B6=C6=DE-YZn=C7(s=1Bm=A7=FF=E5S=CBlm=E9e*=A6=ECr?=BF?=A8=A5= ?=A9=FF-+-Sw=E8=FE=C8=A9 > ------=_NextPart_000_01DD_01C04E65.54F9E2E0 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_01DD_01C04E65.54F9E2E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:03: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 FAA06162 for ; Tue, 14 Nov 2000 05:03:28 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D7C94443B1; Tue, 14 Nov 2000 03:10:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id A231444345 for ; Tue, 14 Nov 2000 03:06:28 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE92bJ03842; Tue, 14 Nov 2000 18:02:37 +0900 Message-ID: <045801c04e1a$2ba00f00$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: Subject: Re: [SIP] Redirect server returning new From header MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0281_01C04E65.66D25E20" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:02:37 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0281_01C04E65.66D25E20 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >Do you actually mean the From: or do you mean the To:? From. >It seems a bit odd for a redirect server to tell the UAC what >From: to use. Perhaps you could give an example of its usage. Well, this is - once again - related to the PSTN/SIP GW issue, if the GW needs a telephone number for some kind of A number analysis. When I make a phone call from my SIP phone I may not know that the call may end up on the PSTN side, so I can for example put my email address in the From header. However, since the network architecture includes a GW to the PSTN network, somewhere there could be a server which is able to do the mapping between the email address user part and a telephone number user part (if SIP URL is used). Regards, Christer Holmberg Ericsson Finland >=20 > Regards, > Sean >=20 > -- > Sean Olson >=20 > Christer Holmberg wrote: >=20 > > Another proposal on the issue, with another use of the "Also-From" > > header. > > > > Currently, a redirect server add a new Request-URI (in the 3xx = response > > Contact header) to the UAC. An idea would be that it could also = return a > > new From header, for example with a telephone number. In this case, = the > > UAC, and intermediate proxies, would not need to insert any extra > > headers or URI parameters in the request. This would be a new, = optional, > > feature in a redirect server. > > > > Comments? > > > > Christer Holmberg > > Ericsson Finland ------=_NextPart_000_0281_01C04E65.66D25E20 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0281_01C04E65.66D25E20-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:11:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08595 for ; Tue, 14 Nov 2000 05:11:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5178B443C0; Tue, 14 Nov 2000 03:10:43 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id E50244435A for ; Tue, 14 Nov 2000 03:07:19 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE93JJ04121; Tue, 14 Nov 2000 18:03:22 +0900 Message-ID: <047901c04e1a$46803f20$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: "Kevin Summers" Cc: "IETF SIP (E-mail)" Subject: Re: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0415_01C04E65.8FF90920" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:03:22 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0415_01C04E65.8FF90920 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Greetings: Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field (RFC 2183) Regards, Bobby.Sardana@mobilerain.com Kevin Summers wrote: > Which RFC defines Content-Disposition and its parameters? > > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: Thursday, November 09, 2000 12:59 PM > To: IETF SIP (E-mail) > Subject: [SIP] WG Last Call on draft-ietf-isup-mime-06.txt > > After one last very minor tweak, I believe we are ready to have a > working-group last call on the ISUP-MIME draft, closing November 23. > > The latest rev has been sent to the drafts editor and can also be = downloaded > from: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-isup-mime-06.txt > > And remember, vote early, vote often. > > -- > Dean Willis > SIP WG co-chair. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > > This footnote also confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > > www.inip.com > ********************************************************************** > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_0415_01C04E65.8FF90920 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0415_01C04E65.8FF90920-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:16: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 FAA10269 for ; Tue, 14 Nov 2000 05:16:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 64022443AD; Tue, 14 Nov 2000 03:10:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 2BA7A44344 for ; Tue, 14 Nov 2000 03:06:28 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE92bJ03834 for ; Tue, 14 Nov 2000 18:02:37 +0900 Message-ID: <045701c04e1a$2b7e7d40$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Subject: [SIP] Redirect server returning new From header MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_027C_01C04E65.66C19540" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:02:37 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_027C_01C04E65.66C19540 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Another proposal on the issue, with another use of the "Also-From" header. Currently, a redirect server add a new Request-URI (in the 3xx response Contact header) to the UAC. An idea would be that it could also return a new From header, for example with a telephone number. In this case, the UAC, and intermediate proxies, would not need to insert any extra headers or URI parameters in the request. This would be a new, optional, feature in a redirect server. Comments? Christer Holmberg Ericsson Finland ------=_NextPart_000_027C_01C04E65.66C19540 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_027C_01C04E65.66C19540-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:21: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 FAA11784 for ; Tue, 14 Nov 2000 05:21:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85E1C4439E; Tue, 14 Nov 2000 03:09:25 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id A98C144336 for ; Tue, 14 Nov 2000 03:05:43 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91fJ03634; Tue, 14 Nov 2000 18:01:41 +0900 Message-ID: <038601c04e1a$0a6ce9c0$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: , , Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01E5_01C04E65.559A1A80" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:41 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_01E5_01C04E65.559A1A80 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Chris Harris wrote: > > > Bobby Sardana wrote: > >> Greetings Chris: >> >> Just to add a pointer to this thread: >> >> Maintaining trasaction state is an application level functionality >> and *shouldn't* be implemented in the base stack. For applications >> like state oriented proxy server, the JAIN SIP can provide enough >> hooks for event delivery but the state has to be maintained by the >> proxy server. > > Is simply sending up all received requests without any kind of > transaction id really enough? Yes. In the case of SIP there actually is no such thing as TransactionID, compared to some other protocols like TCAP. The TrasactionID in case of SIP is a composite collection of headers. The headers, once parsed, are available to the application. The application then should track what state it should maintain. It is equivalent to a Call Model vs Encoding/Decoding of protocols like INAP. > What are the hooks you refer to? The hooks I refer to are the delegation event delivery mechanism via JainSipListener. > An application like a stateful proxy server will surely be able to > handle this, but what about simple services? - shouldn't the API > provide a convenient means to send responses, acks, cancel etc? Here you are referring to the Call Model - which manages the protocol/application state. All I am suggesting is that it should be independent of the stack. Regards, Bobby.Sardana@mobilerain.com > > >> >> >> Pleas keep up the good work. It is really appreciated. >> >> Regards, >> >> Bobby.Sardana@mobilerain.com >> >> Chris Harris wrote: >> >> > "M. Ranganathan" wrote: >> > >> >> Hi Chris, >> >> >> >> Thanks for replying so promptly (I am sure you are flooded with >> >> email ). >> > >> > I get one or two :) >> > >> >> >> >> As you pointed out, I suppose we cannot do away with making >> >> Messages >> >> into classes because of the tie-in with java events >> >> (unfortunately) but >> >> I still like the notion of being able to specify interfaces >> >> where ever >> >> possible. >> > >> > I see where you're coming from alright, and I suppose changing >> > header classes into interfaces, could fit in with Gethin's proposal >> > nicely? >> > >> >> >> >> I dont quite follow the motivation behind the following design >> >> decision (excerpted from your reply): >> >> >> >> Maybe I've misunderstood what you're saying - but a JAIN SIP >> >> implementation is only stateless when it comes to call state. The >> >> >> >> JainSipProvider implementation must maintain transaction state - >> >> it >> >> simply exposes a reference to a transaction via the transaction >> >> id for >> >> the convenience of the JainSipListener. The service does not have >> >> total >> >> control over transacton state - the stack implementation does. >> >> >> >> It appears that I have indded mis-understood the architecture. >> >> Why >> >> should the above be so? Can one not rely on the JainSipListener >> >> to keep >> >> transaction state also, thereby making the stack simply a way of >> >> recognising messages and triggering event handlers on the basis >> >> of >> >> message type. This would (IMHO) be a cleaner model yet. That >> >> way, we >> >> can do away with transaction identifiers being passed back and >> >> forth and >> >> keep all of this information in the handler. ( You may have to >> >> extend >> >> the architecture somewhat to deal with timeouts and failures so >> >> that the >> >> handler knows about transaction failure.) In any case, if this is >> >> not a >> >> viable idea, I would be grateful if you can explain why not (or >> >> point me >> >> to the portion of the spec that explains why not) so I can get a >> >> better >> >> understanding. >> > >> > It would be cleaner model, and personally I am in total agreement >> > with you - but it means the application is forced to maintain >> > transaction state, match up headers - which has been said places >> > too much of a burden on applications. How about finding a way to >> > let the application choose whether or not it wants to keep >> > transaction state? >> > >> >> >> >> >> >> Regards, >> >> >> >> Ranga. >> >> >> >> Chris Harris wrote: >> >> >> >> > Hi Ranga, >> >> > >> >> > Response below... >> >> > >> >> > Chris >> >> > >> >> > "M. Ranganathan" wrote: >> >> > >> >> >> JAIN-SIP is a groovy idea. Hats off to the whole concept and >> >> many >> >> >> thanks to Chris and >> >> >> the JAIN-SIP team for putting together a spec and more flower >> >> power >> >> >> to them :-) . In >> >> >> particular I like the notion of treating UAS, Redirect and >> >> Proxy >> >> >> servers as merely >> >> >> special cases of the general notion of Services and the idea >> >> of >> >> >> unifying these >> >> >> notions with an event mechanism and event handlers. Second, >> >> I like >> >> >> the idea of >> >> >> separation between a stateless event -oriented "stack" and a >> >> bunch >> >> >> of event >> >> >> handlers that are triggered by the stack with all state >> >> (including >> >> >> transaction >> >> >> state) being separated from the event stack via the JAIN-SIP >> >> mapping >> >> >> layer if you >> >> >> will. ( Correct me if I wax poetic but have the wrong >> >> >> understanding....) >> >> > >> >> >> >> >> >> >> >> >> I hope I will not be viewed as being too critical, but I >> >> would >> >> >> like to go one step >> >> >> further than what Gethin is suggesting. I am all for using >> >> >> interfaces as much as >> >> >> possible and leaving class hierarchy definitions to >> >> implemeters. >> >> >> Defining class >> >> >> hierarchies almost lays out an implementation and involves >> >> >> considerable rework for >> >> >> those who have a working java-based stack, but have not used >> >> the >> >> >> same classes. OK it >> >> >> is just a matter of labor to map things to the JAIN-SIP class >> >> >> hierarchy but it IS a >> >> >> dis-incentive. >> >> >> >> >> >> 1. Lets use interfaces for all messages rather than actually >> >> define >> >> >> class >> >> >> hierarchies ( yes Chris has pointed out the historical >> >> precedent >> >> >> behind actually >> >> >> defining class hierarchies for messages. IMHO, there has to >> >> be a >> >> >> more compelling >> >> >> reason than that.) >> >> > >> >> > I suppose all classes could be turned into interfaces, except >> >> for the >> >> > Message classes which must extend java.util.EventObject to fit >> >> into >> >> > the JAIN framework. >> >> > >> >> >> >> >> >> >> >> >> 2. The tie-in with the JAVA event mechanism has necessitated >> >> the >> >> >> explicit definition >> >> >> of class hierarchies in certain places. Why not use callbacks >> >> >> >> >> instead and do away >> >> >> with this dependency as well? (Basically the same thing as >> >> events >> >> >> but does not tie >> >> >> into the JAVA event mechanism and its associated limitations.) >> >> >> >> > >> >> > Unfortunately the JAIN framework expilicitly relies on the Java >> >> Event >> >> > model, and I don't think callbacks would be accepted within the >> >> JAIN >> >> > community. >> >> > >> >> >> >> >> >> >> >> >> Nice work and keep it rolling! Thanks. >> >> > >> >> > Couldn't do it without you guys - thank you! >> >> > >> >> >> >> >> >> >> >> >> Ranga. >> >> >> >> >> >> Gethin Liddell wrote: >> >> >> >> >> >> > All, >> >> >> > >> >> >> > This idea of abstraction of the JAIN API is certainly a >> >> valid and >> >> >> > interesting idea. However, i'm a bit concerened that the >> >> proposed >> >> >> >> >> >> > solution of many different packages, will only seek to >> >> complicate >> >> >> and >> >> >> > maybe enlarge the API. >> >> >> > >> >> >> > I too see no reason why there is an EntityHeader etc... and >> >> i also >> >> >> do >> >> >> > not see any requirement for an InviteMessage, AckMessage >> >> etc... >> >> >> > >> >> >> > How about if the format of the API remains as is: >> >> >> > >> >> >> > jain.protocol.ip.sip >> >> >> > jain.protocol.ip.sip.header >> >> >> > jain.protocol.ip.sip.message >> >> >> > >> >> >> > except that the messages available in the message package >> >> >> consisted of >> >> >> > BasicRequest/Response, MinimalRequest/Response etc... where >> >> each >> >> >> > message is extened in turn (e.g. Minimal extends Basic, >> >> Moderate >> >> >> > extends Minimal etc...), of course as Chris points out it is >> >> not >> >> >> hard >> >> >> > to see that a combination would be required that is not >> >> provided. >> >> >> So >> >> >> > in the interest of flexibility, it could be possible for the >> >> user >> >> >> to >> >> >> > plug-in to the message class what extra headers it >> >> requires. The >> >> >> only >> >> >> > issue then is that the user will have to use a "public >> >> Header >> >> >> > getHeader(String headerName)" and then cast the header to >> >> their >> >> >> desired >> >> >> > header type. Either that or create their own Message class >> >> >> > (extending the current ones) that simply does the casting >> >> >> automatically >> >> >> > for them. Then after compiling, run an obfuscator on the >> >> code and >> >> >> it >> >> >> > will automatically extract and only extract the Message, >> >> Headers >> >> >> and >> >> >> > even methods that are used. >> >> >> > >> >> >> > This then will also cut down on the number of methods in the >> >> >> >> >> Provider >> >> >> > as there will be no need for the sendAck(AckMessage), >> >> >> > sendInvite(InviteMessage) etc.. as they would be replaced by >> >> the >> >> >> > single method sendRequest(RequestMessage). >> >> >> > >> >> >> > I personally see three arguments for keeping the JAIN SIP >> >> stack as >> >> >> small >> >> >> > as possible: >> >> >> > >> >> >> > 1) The first is for embedded applications where stack size >> >> has to >> >> >> be >> >> >> > kept to a minimum as memory is at a premium. So if just >> >> using the >> >> >> >> >> >> > Basic message suffices then this will compile and run with a >> >> small >> >> >> >> >> >> > number of classes present from the stack. Don't forget, >> >> >> obfuscation >> >> >> > will help in extracting only the Messages, Headers and even >> >> >> methods >> >> >> > required from a jar file but it won't do everything. >> >> >> > >> >> >> > 2) The second is that users may be put off or confused by >> >> the >> >> >> sheer >> >> >> > size and complexity of the JAIN stack. So if only using the >> >> >> >> >> > BasicMessage gets them on the first rung of the ladder then >> >> it is >> >> >> a >> >> >> > good starting point and allows them to build up to bigger >> >> and >> >> >> better >> >> >> > things. >> >> >> > >> >> >> > 3) We also have to consider who is going to implement the >> >> JAIN SIP >> >> >> >> >> >> > stack. If it is indeed overly complicated then no-one or a >> >> single >> >> >> > vendor may end up implmenting the stack and thus its >> >> definition >> >> >> and >> >> >> > all the hard work that has gone into it is useless. >> >> >> > >> >> >> > On Mon, 16 Oct 2000, Chris Harris wrote: >> >> >> > > Itamar, >> >> >> > > >> >> >> > > The idea of levelling the API based on what messages, >> >> headers >> >> >> and response codes >> >> >> > > are understood is certainly an interesting one - minimal, >> >> basic, >> >> >> redirection, >> >> >> > > firewall-friendly, negotiation, authentication and "full". >> >> >> >> >> > > >> >> >> > > jain.protocol.ip.sip >> >> >> > > jain.protocol.ip.sip.header >> >> >> > > jain.protocol.ip.sip.message >> >> >> > > >> >> >> > > could then become... >> >> >> > > >> >> >> > > jain.protocol.ip.sip - listener, provider, stack, general >> >> >> classes used at all >> >> >> > > levels >> >> >> > > jain.protocol.ip.sip.header - contains base Header class >> >> (and >> >> >> requestHeader, >> >> >> > > ResponseHeader, EntityHeader, GeneralHeader) >> >> >> > > jain.protocol.ip.sip.message - contains base Message class >> >> >> >> >> > > >> >> >> > > jain.protocol.ip.sip.minimal - general classes used only >> >> at this >> >> >> level and above >> >> >> > > >> >> >> > > jain.protocol.ip.sip.minimal.header - headers used only at >> >> this >> >> >> level and above >> >> >> > > jain.protocol.ip.sip.minimal.message - messages only used >> >> at >> >> >> this level and >> >> >> > > above >> >> >> > > >> >> >> > > jain.protocol.ip.sip.basic - general classes used only at >> >> this >> >> >> level and above >> >> >> > > jain.protocol.ip.sip.basic.header - headers used only at >> >> this >> >> >> level and above >> >> >> > > jain.protocol.ip.sip.basic.message - messages used only at >> >> this >> >> >> level and above >> >> >> > > ... >> >> >> > > .... >> >> >> > > jjain.protocol.ip.sip."full" - general classes only used >> >> at this >> >> >> level >> >> >> > > jain.protocol.ip.sip."full".header - headers used only at >> >> this >> >> >> level >> >> >> > > jain.protocol.ip.sip."full".message - messages used only >> >> at this >> >> >> level >> >> >> > > >> >> >> > > The API user could then pick the packages they need - say >> >> they >> >> >> initially only >> >> >> > > want the minimal features, but then realise they need to >> >> use >> >> >> their application >> >> >> > > behind a firewall - then they can simply add the >> >> >> firewall-friendly package. The >> >> >> > > RFC says "In general, each capability listed builds on the >> >> ones >> >> >> above it" but it >> >> >> > > is not hard to see that firewall-friendly and >> >> authentication may >> >> >> be desired >> >> >> > > without redirection for example. >> >> >> > > >> >> >> > > Is this what you hand in mind Itamar? >> >> >> > >> >> >> > -- >> >> >> > Gethin Liddell >> >> >> > Ubiquity Software Corporation >> >> >> > >> >> >> > http://www.ubiquity.net >> >> >> > mailto:gethin@ubiquity.net >> >> >> > >> >> >> > _______________________________________________ >> >> >> > SIP mailing list >> >> >> > SIP@lists.bell-labs.com >> >> >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> >> >> >> >> -- >> >> >> M.Ranganathan >> >> >> NIST Advanced Networking Technologies Group, >> >> >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> >> >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> >> >> >> >> Hf=E6j)b? = b=B2=D4^>X=AC=B6=C6=DE-YZn=C7(s=1Bm=A7=FF=E5S=CBlm=E9e*=A6=ECr?=BF?=A8=A5= ?=A9=FF-+-Sw=E8=FE=C8=A9 >> >> > >> >> >> >> -- >> >> M.Ranganathan >> >> NIST Advanced Networking Technologies Group, >> >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> >> Tel: 301 975 3664 Fax: 301 590 0932 >> >> >> >> Hf=E6j)b? = b=B2=D4^>X=AC=B6=C6=DE-YZn=C7(s=1Bm=A7=FF=E5S=CBlm=E9e*=A6=ECr?=BF?=A8=A5= ?=A9=FF-+-Sw=E8=FE=C8=A9 >> > ------=_NextPart_000_01E5_01C04E65.559A1A80 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_01E5_01C04E65.559A1A80-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:24: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 FAA12892 for ; Tue, 14 Nov 2000 05:24:28 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E69DF443D7; Tue, 14 Nov 2000 03:10:59 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id B282044346 for ; Tue, 14 Nov 2000 03:06:28 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE92bJ03849; Tue, 14 Nov 2000 18:02:37 +0900 Message-ID: <045901c04e1a$2bc1a0c0$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Anders Kristensen" Subject: Re: [SIP] Redirect server returning new From header MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0286_01C04E65.66EAC820" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:02:37 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0286_01C04E65.66EAC820 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >>Another proposal on the issue, with another use of the "Also-From" >>header. >> >>Currently, a redirect server add a new Request-URI (in the 3xx = response >>Contact header) to the UAC. An idea would be that it could also return = a >>new From header, for example with a telephone number. In this case, = the >>UAC, and intermediate proxies, would not need to insert any extra >>headers or URI parameters in the request. This would be a new, = optional, >>feature in a redirect server. >=20 >A registrar is free to return SIP, tel:, mailto:, http: and any other >kind of URLs in Contacts. Whatever it is you think you need the extra >From for I think you'll find you can use Contact for. I know, but the idea was to give the possibility not only to return a new RequestURI - whatever format - in the Conact header, but also to give a new From header, if for example the Redirect server knows that the request will reach a PSTN/IP GW, and the current From header can for example not be used for A number analysis. I want to point out that this case is not about solving a bug in the protocol itself, it has to do only with the interworking architecture with PSTN. Regards, Christer Holmberg Ericsson Finland ------=_NextPart_000_0286_01C04E65.66EAC820 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0286_01C04E65.66EAC820-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:26: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 FAA13593 for ; Tue, 14 Nov 2000 05:26:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B34CC44398; Tue, 14 Nov 2000 03:09:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 625B844336 for ; Tue, 14 Nov 2000 03:05:29 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91VJ03584; Tue, 14 Nov 2000 18:01:31 +0900 Message-ID: <037001c04e1a$07ad7ba0$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Brett Tate" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01B8_01C04E65.50FB8C20" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:31 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_01B8_01C04E65.50FB8C20 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >>While it is true that there are other ways that this could have been >>solved, it is pretty late in the game to make this kind of a change. = >>Especially if the only reason for doing so is to avoid the ACK = message. >Other reasons include the desire not to revive a >dead session and to avoid the possibility of a new >SDP in the 200 response. True. Regards, Christer Holmberg Ericsson Finland >>As a side note, we are in the process of creating a new version of the >>draft that we hope will be used for working group last call. >=20 > Steve, >=20 > Can a header or parameter be defined within > the sip-session-timer to indicate that the sender > is just trying to extend the Session-Timer and > check session state, but the sender does NOT > want the session revived if it is down? The > reverse of the boolean value could indicate a > request to revive the session if it is down. >=20 > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_01B8_01C04E65.50FB8C20 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_01B8_01C04E65.50FB8C20-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:27: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 FAA13954 for ; Tue, 14 Nov 2000 05:27:45 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C183C443E1; Tue, 14 Nov 2000 03:11:21 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 5236E44348 for ; Tue, 14 Nov 2000 03:06:29 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE92cJ03859; Tue, 14 Nov 2000 18:02:38 +0900 Message-ID: <045a01c04e1a$2c04c440$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Hisham Khartabil" Subject: Re: [SIP] Redirect server returning new From header MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_028B_01C04E65.6758A520" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:02:38 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_028B_01C04E65.6758A520 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >I see what you are trying to achieve here, but my concern is with the >redirection rules. When a UA gets a 3xx response, it issues a new = >request. MUST that new request belong to the same call leg as the = >original request? >ie: same To: From: Call-id, but higher Cseq. If so, your proposal = breaks >that rule. It doesn't have to belong to the same call leg. It MAY do so, but you MAY also change the To header (with the new value in the 3xx response Contact header), and you MAY also change the Call-id value. And, in any case, it doesn't affect anything else than my own implementation, even if I use the same Call-id (which one would probably do).=20 I mean - I don't even have to issue a new INVITE when I receive a 3xx, so any possible intermediate SIP proxy etc. should not be affected. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: sip-admin@lists.bell-labs.com = [mailto:sip-admin@lists.bell-labs.com]On > Behalf Of Christer Holmberg > Sent: 24. lokakuuta 2000 14:02 > To: sip@lists.bell-labs.com > Cc: Anders Kristensen > Subject: Re: [SIP] Redirect server returning new From header >=20 > Hi, >=20 > >>Another proposal on the issue, with another use of the "Also-From" > >>header. > >> > >>Currently, a redirect server add a new Request-URI (in the 3xx = response > >>Contact header) to the UAC. An idea would be that it could also = return a > >>new From header, for example with a telephone number. In this case, = the > >>UAC, and intermediate proxies, would not need to insert any extra > >>headers or URI parameters in the request. This would be a new, = optional, > >>feature in a redirect server. > > > >A registrar is free to return SIP, tel:, mailto:, http: and any other > >kind of URLs in Contacts. Whatever it is you think you need the extra > >From for I think you'll find you can use Contact for. >=20 > I know, but the idea was to give the possibility not only to return a > new RequestURI - whatever format - in the Conact header, but also to > give a new From header, if for example the Redirect server knows that > the request will reach a PSTN/IP GW, and the current From header can = for > example not be used for A number analysis. >=20 > I want to point out that this case is not about solving a bug in the > protocol itself, it has to do only with the interworking architecture > with PSTN. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland ------=_NextPart_000_028B_01C04E65.6758A520 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_028B_01C04E65.6758A520-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05: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 FAA14502 for ; Tue, 14 Nov 2000 05:29:26 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8774E443ED; Tue, 14 Nov 2000 03:11:43 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 6F7394434E for ; Tue, 14 Nov 2000 03:06:54 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE931J04040; Tue, 14 Nov 2000 18:03:01 +0900 Message-ID: <047101c04e1a$39ab0780$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: Subject: Re: [SIP] Content-Length values in RFC and call flows examples MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0389_01C04E65.7AB1A5E0" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:03:01 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0389_01C04E65.7AB1A5E0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Greetings: "M. Ranganathan" wrote: > Here is a straightforward question regarding the examples in the RFC = and > sip call flows documents. > > Are the Content-Length values computed on the basis of CR-LF (2 > characters) for newline? (i.e. DOS vs UNIX convention)? Yes. Regards, Bobby.Sardana@mobilerain.com > > > Thank you in advance for your replies. > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > Hf=E6j)b? = b=B2=D4^>X=AC=B6=C6=DE-YZn=C7(s=1Bm=A7=FF=E5S=CBlm=E9e*=A6=ECr?=BF?=A8=A5= ?=A9=FF-+-Sw=E8=FE=C8=A9 ------=_NextPart_000_0389_01C04E65.7AB1A5E0 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0389_01C04E65.7AB1A5E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:34: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 FAA16031 for ; Tue, 14 Nov 2000 05:34:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 02856443DC; Tue, 14 Nov 2000 03:11:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id A49E144349 for ; Tue, 14 Nov 2000 03:06:29 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE92cJ03862; Tue, 14 Nov 2000 18:02:38 +0900 Message-ID: <045b01c04e1a$2c2df720$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Hisham Khartabil" Subject: Re: [SIP] Redirect server returning new From header MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0290_01C04E65.67710F20" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:02:38 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0290_01C04E65.67710F20 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, Well, you may use the same call-ID value (the value should be unique for the call, not for a single call leg), but you are still allowed to change the To- and From headers. And, chapter 7.3.3. says that the call-ID value can also be changed. Regards, Christer Holmberg Ericsson Finland Hisham Khartabil wrote: >=20 > I can't find in the bis where it says that they belong to the same = call leg, > but in section 1.4.4 the last paragraph, it does say "The caller = issues a > new request, > with the same call-ID but a higher CSeq, to the address returned by = the > first server" >=20 > Hisham >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 24. lokakuuta 2000 14:47 > To: sip@lists.bell-labs.com > Cc: Hisham Khartabil > Subject: Re: [SIP] Redirect server returning new From header >=20 > Hi, >=20 > >I see what you are trying to achieve here, but my concern is with the > >redirection rules. When a UA gets a 3xx response, it issues a new > >request. MUST that new request belong to the same call leg as the = >original > request? > >ie: same To: From: Call-id, but higher Cseq. If so, your proposal = breaks > >that rule. >=20 > It doesn't have to belong to the same call leg. It MAY do so, but you > MAY also change the To header (with the new value in the 3xx response > Contact header), and you MAY also change the Call-id value. >=20 > And, in any case, it doesn't affect anything else than my own > implementation, even if I use the same Call-id (which one would = probably > do). > I mean - I don't even have to issue a new INVITE when I receive a 3xx, > so any possible intermediate SIP proxy etc. should not be affected. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On > > Behalf Of Christer Holmberg > > Sent: 24. lokakuuta 2000 14:02 > > To: sip@lists.bell-labs.com > > Cc: Anders Kristensen > > Subject: Re: [SIP] Redirect server returning new From header > > > > Hi, > > > > >>Another proposal on the issue, with another use of the "Also-From" > > >>header. > > >> > > >>Currently, a redirect server add a new Request-URI (in the 3xx = response > > >>Contact header) to the UAC. An idea would be that it could also = return a > > >>new From header, for example with a telephone number. In this = case, the > > >>UAC, and intermediate proxies, would not need to insert any extra > > >>headers or URI parameters in the request. This would be a new, = optional, > > >>feature in a redirect server. > > > > > >A registrar is free to return SIP, tel:, mailto:, http: and any = other > > >kind of URLs in Contacts. Whatever it is you think you need the = extra > > >From for I think you'll find you can use Contact for. > > > > I know, but the idea was to give the possibility not only to return = a > > new RequestURI - whatever format - in the Conact header, but also to > > give a new From header, if for example the Redirect server knows = that > > the request will reach a PSTN/IP GW, and the current From header can = for > > example not be used for A number analysis. > > > > I want to point out that this case is not about solving a bug in the > > protocol itself, it has to do only with the interworking = architecture > > with PSTN. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland ------=_NextPart_000_0290_01C04E65.67710F20 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0290_01C04E65.67710F20-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:38: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 FAA17467 for ; Tue, 14 Nov 2000 05:38:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C31514437E; Tue, 14 Nov 2000 03:08:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 26C7C4433B for ; Tue, 14 Nov 2000 03:05:15 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91NJ03545; Tue, 14 Nov 2000 18:01:24 +0900 Message-ID: <030a01c04e19$ffc93820$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Bryan Byerly" , , Subject: Re: [SIP] From header to ISUP CgPN mapping MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0198_01C04E65.4E86E2A0" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:24 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0198_01C04E65.4E86E2A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >ok. Thanks for clearing that up. >=20 >A follow-up question: >How does/does Also-From header differ from the Remote-Party-Id header >(draft-dcsgroup-sip-privacy-02.txt)? Well, it could perhaps be possible to use that header, but the whole concept of that draft is a little different than just adding an telephone number alias to the caller, and by supporting it I guess you would have to do more implementation than necessary for this specfic need. Also, depending on what is put in Remote-Party-Id header, it is not even sure it would solve the problem. Regards, Christer Holmberg Ericsson Finland > Thanks for your help! > Bryan >=20 > Christer Holmberg wrote: >=20 > > Hi, > > > > Using the Diversion header, you can inform an endpoint of which > > Request-URIs have been used before the Request-URI of that specific > > endpoint was used. > > > > The case I am talking about, however, is when we can insert an = "alias" > > header for the From header, using a telephone number, if the From = header > > is, for example, an e-mail address. Using this new header, let us = call > > is Also-From, a proxy (or the calling endpoint itself) may also = insert a > > telephone number, which can then be used by PSTN Gateways for any = kind > > of A-number analysing. One could argue that the caller should always > > include a telephone number in the From header, but the caller may = not > > know that the call will end up on the PSTN side, so... > > > > I DO like the Diversion draft very much, though, but it doesn't = solve > > this specific problem :) > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Bryan Byerly wrote: > > > > > > Hi guys, > > > > > > What do you guys think about using the Diversion header > > > = (http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-00.txt) = instead of > > > Also-From? > > > It seems like a natural replacement to me. > > > > > > Thanks! > > > Bryan > > > > > > Christer Holmberg wrote: > > > > > > > Hi, > > > > > > > > This is something I've also been looking into. > > > > > > > > One way would be to add a new header (e.g. Also-From). That = header could > > > > be inserted by a proxy that does know the request may end up in = a > > > > gateway. The UA may not know that, so he could put whatever = string in > > > > the user part of the From header (e.g. his e-mail address). If = the proxy > > > > then knows the UAs telephone number, for example by using some = kind of > > > > database lookup, which is needed by the gateway - for any = possible > > > > A-number procedure - the proxy can add that to the request. > > > > > > > > Another way would be to just define a URI parameter for the From = header, > > > > but the bad thing about that is that it can not be inserted by a = proxy > > > > if it was not in the request from the UA (since the From header = must not > > > > be changed) by a proxy, or any other intermediate node. > > > > > > > > Note, that this response is according to Clive's mail. I do NOT = support > > > > the idea of ALSO-TO headers, multiple FROM/TO headers and = whatever was > > > > proposed in the previous mails :) > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > clive.dellard@bt.com wrote: > > > > > > > > > > I agree with what you say, however, if you consider a call = originating from > > > > > a SIP device (telephone or softphone) that ends up going = through a gateway > > > > > to the PSTN then it is a different story. > > > > > Neither the user or the UAC can know where a call will end up, = therefore the > > > > > ability to be able to provide both SIP address and SIP = Telephone number > > > > > would be useful to providing a complete service as then an = appropriate > > > > > calling address is available wherever the call ends up. In the = scenario I > > > > > described the gateway could chose the Telephone number (ok I = know there are > > > > > verification issues but that's another story). > > > > > Something like Simon's idea of an "ALSO-FROM" seems a good = idea to me (this > > > > > is similar to "two number delivery" in the ISDN CLIP service) = older versions > > > > > would just ignore the ALSO-FROM and it wouldn't affect the = significance of > > > > > the FROM and TO headers. > > > > > > > > > > Clive > > > > > > > > > > > -----Original Message----- > > > > > > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > > > > > > Sent: Wednesday, October 11, 2000 7:41 PM > > > > > > To: 'clive.dellard@bt.com'; 'sip@lists.bell-labs.com' > > > > > > Subject: RE: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: clive.dellard@bt.com [mailto:clive.dellard@bt.com] > > > > > > > Sent: Wednesday, October 11, 2000 12:17 PM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > Subject: [SIP] From header to ISUP CgPN mapping > > > > > > > > > > > > > > > > > > > > > In the call flows document = draft-ietf-sip-call-flows-01.txt, > > > > > > > scenario 4.1.1, > > > > > > > the message detail and text show User A using a SIP = telephone > > > > > > > number rather > > > > > > > than a SIP address in the From header. The text at the > > > > > > > beginning of section > > > > > > > 4 also says "that User A still uses his/her SIP URL in the > > > > > > > Contact header, > > > > > > > since the call could be redirected back to the SIP = network." > > > > > > > This implies that User A has pre-knowledge that the call = is > > > > > > > going to route > > > > > > > to the PSTN and has the ability to chose the address to be > > > > > > > used in the From > > > > > > > header. > > > > > > > > > > > > No. > > > > > > > > > > > > The From header is the logical identity of the user making = the call. Since > > > > > > the call is coming through a gateway, that user is some user = on a PSTN > > > > > > terminal somewhere. The identity in this case can either be = a tel URL, or > > > > > > a > > > > > > SIP URL at the domain of the originating network. > > > > > > > > > > > > The Contact is used for signaling addressing. Its not a = logical > > > > > > identifier. > > > > > > It answers the question "where should I send SIP messages to = for the rest > > > > > > of > > > > > > this call". The SIP spec says this is supposed to be a SIP = URL preferably > > > > > > with a complete hostname, so that there are no ambiguities = about where to > > > > > > send requests. > > > > > > > > > > > > Neither of these have anything to do with knowing where the = call is going. > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > --- > > > > > > Jonathan D. Rosenberg 72 Eagle Rock = Ave. > > > > > > Chief Scientist First Floor > > > > > > dynamicsoft East Hanover, NJ = 07936 > > > > > > jdrosen@dynamicsoft.com FAX: (973) = 952-5050 > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) = 952-5000 > > > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_0198_01C04E65.4E86E2A0 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0198_01C04E65.4E86E2A0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:42: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 FAA18803 for ; Tue, 14 Nov 2000 05:42:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0CBCB4436E; Tue, 14 Nov 2000 03:07:57 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id EB88B44336 for ; Tue, 14 Nov 2000 03:05:13 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91NJ03526; Tue, 14 Nov 2000 18:01:23 +0900 Message-ID: <02fd01c04e19$ff322840$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Lars Berggren" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0190_01C04E65.4E6E78A0" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:23 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_0190_01C04E65.4E6E78A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >>>I think the re-INVITE mechanism is far more better because the = >information about what session is refreshed >>>is carried in the SDP of = the re-INVITE. The INFO approach has the significant disadvantage that = >proxies >>>that use the session timer might have to store a *lot* of = state information about each session. >>That is not true. The session is identified using the Call-ID. >The call-id is the SIP-identifier of a session, yes. But, SIP >initiates a multimedia session and if the proxy is doing stuff (like >allocating some sort of network resources for a limited period of >time) related to the multimedia session and is interested in knowing = when >that session ends it might add a session timer. Now, if all the >information that set up the session gets repeated in the re-INVITE the >proxy does not have to store call-id etc together with the multimedia >session parameters to track which multimedia session the >SIP-message refers to. Well, that is true, but that is a very application specific issue. I don't think it's a big problem for the proxy to store the necessary session data (the endpoints have to store it too, to be able to resend it in the re-INVITEs), together with the Call-Id (you need to store the Call-ID in any case), compared to the fact that you save lots of resources, both in the network and due to the fact that the logic of the endpoints gets more simple. Regards, Christer Holmberg Ericsson Finland >=20 > Regards, >=20 > /Lars >=20 > > > > In fact, another advantage of using INFO is that you don't have to = send > > a message body at all. Using re-INVITE, you must send a copy of the > > original message, and the UAS must check if the SDP is a copy > > (session-timer) or if it is a new SDP, when the session should be > > modified. Again, we save resources. Comments? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > Regards /Lars > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > Lars Berggren > > > Intertex Data AB tel: +46-8-6282828 > > > Sundbyberg, Sweden fax: +46-8-6286414 >=20 > Lars Berggren > Intertex Data AB tel: +46-8-6282828 > Sundbyberg, Sweden fax: +46-8-6286414 ------=_NextPart_000_0190_01C04E65.4E6E78A0 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_0190_01C04E65.4E6E78A0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05:46: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 FAA20045 for ; Tue, 14 Nov 2000 05:46:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ECCA244378; Tue, 14 Nov 2000 03:08:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 5F7E44433C for ; Tue, 14 Nov 2000 03:05:15 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91OJ03548 for ; Tue, 14 Nov 2000 18:01:24 +0900 Message-ID: <030f01c04e1a$0004ba80$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Subject: [SIP] Question on SIP Caller Preferences draft MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_019C_01C04E65.4E97AB80" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:24 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_019C_01C04E65.4E97AB80 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, I would like to clarify one issue in the SIP Caller Preferences draft (draft-ietf-sip-callerprefs-02.txt). The case is when I talk to a SIP server acting as both proxy and redirect. I want it to be able to send me 3xx responses ("redirect"), and I want it to be able to act like a proxy ("proxy"). Also, if it forks a request, and receives a 3xx response, I want it to be forwarded back to me ("no-recurse"). The draft says (chapter 5.5 Request-Disposition) that the recurese-feature is ignored if redirect has been requested, so I can not use the following header: Request-Disposition: proxy, redirect, no-recurse Should I instead use two different headers in the message? I.e.: Request-Disposition: proxy, no-recurse Request-Disposition: redirect (Note: I left the parallel- and fork-feature from the example on purpose) Regards, Christer Holmberg Ericsson Finland ------=_NextPart_000_019C_01C04E65.4E97AB80 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_019C_01C04E65.4E97AB80-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 05: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 SMTP id FAA22240 for ; Tue, 14 Nov 2000 05:53:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6359F443E6; Tue, 14 Nov 2000 03:11:32 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 809B844336 for ; Tue, 14 Nov 2000 03:06:33 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE92gJ03878; Tue, 14 Nov 2000 18:02:42 +0900 Message-ID: <045e01c04e1a$2ebc9140$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Igor Slepchin" , Subject: Re: [SIP] Redirect server returning new From header MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02AB_01C04E65.690B8540" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:02:42 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_02AB_01C04E65.690B8540 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >You can use URL headers to specify SIP message headers, e.g., the = Contact >in the 302 may look like >=20 >Contact: sip:chirster@ericsson?from=3Dtel:12345 >=20 >It's then up to the UAC to trust your redirect server and overwrite its >default From header. See section 2 of 2543bis for details. True, but in this case the redirect server (what I mean by that is actually any SIP node, server or UA, with redirect functionality...) will not know if the UAC is going to use the new header or not. For some reason, the redirect server may behave in different ways (maybe, in some case, it won't even allow the UAC to contact a certain host if the feature is not supported...) depending on if it can give the UAC a new >From header or not. But, if we have a new header for this, the UAC can indicate in the Supported header that it supports this feature. Then, the redirect server can add the new "Also-From" header in the response, and indicate in the Require header that the UAC must use it. Maybe this is possible also in the case where you just add it to the Contact header, but in any case I think you would have to define a new Supported/Require tag value (?) Regards, Christer Holmberg Ericsson Finland >=20 > --- > Igor Slepchin >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, October 24, 2000 5:39 AM > > To: sip@lists.bell-labs.com > > Cc: sean.olson@ericsson.com > > Subject: Re: [SIP] Redirect server returning new From header > > > > > > > > Hi, > > > > >Do you actually mean the From: or do you mean the To:? > > > > From. > > > > >It seems a bit odd for a redirect server to tell the UAC what > > >From: to use. Perhaps you could give an example of its usage. > > > > Well, this is - once again - related to the PSTN/SIP GW > > issue, if the GW > > needs a telephone number for some kind of A number analysis. > > When I make > > a phone call from my SIP phone I may not know that the call may end = up > > on the PSTN side, so I can for example put my email address > > in the From > > header. However, since the network architecture includes a GW to the > > PSTN network, somewhere there could be a server which is able > > to do the > > mapping between the email address user part and a telephone > > number user > > part (if SIP URL is used). > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > Regards, > > > Sean > > > > > > -- > > > Sean Olson > > > > > > Christer Holmberg wrote: > > > > > > > Another proposal on the issue, with another use of the = "Also-From" > > > > header. > > > > > > > > Currently, a redirect server add a new Request-URI (in > > the 3xx response > > > > Contact header) to the UAC. An idea would be that it > > could also return a > > > > new From header, for example with a telephone number. In > > this case, the > > > > UAC, and intermediate proxies, would not need to insert any = extra > > > > headers or URI parameters in the request. This would be a > > new, optional, > > > > feature in a redirect server. > > > > > > > > Comments? > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > ------=_NextPart_000_02AB_01C04E65.690B8540 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_02AB_01C04E65.690B8540-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 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 FAA22777 for ; Tue, 14 Nov 2000 05:55:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ACE08443B6; Tue, 14 Nov 2000 03:10:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id 0709D44348 for ; Tue, 14 Nov 2000 03:06:40 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE92nJ03909 for ; Tue, 14 Nov 2000 18:02:49 +0900 Message-ID: <046501c04e1a$32902e80$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Subject: RE: [SIP] Redirect server returning new From header MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02E4_01C04E65.6D5DC860" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:02:49 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_02E4_01C04E65.6D5DC860 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable > I thought we had put this issue to bed. > > As Henning pointed out previously, allowing a UAC to insert a = telephone > number into a request, which is then passed to the PSTN (via a = gateway) as > the originating number, is a recipe for a security disaster. Nothing = stops > me from inserting fake telephone numbers, and calling people = pretending to > be someone else. You can expect a call from the FCC about that one. > > So, in fact, this proposed used of the Also-From header is, in = practice, > unusable without a massive security/PKI infrastructure which really = doesn't > exist (you would need someone to certify that joe@foo.com owns the = number > 555-1212. I don't even know who would be able to adequately certify = this, > and I suspect no CA in their right mind would ever put this in a > certificate). This security infrastructure already exists in the current telephone = network - although it is implemented in hardware rather than software. Phone = companies have a network of trust with each other, and exchange ISUP messages with each = other only secure lines setup along these lines of trust. Where signalling is = exchanged with an end user (Q.931) checks are made to ensure the user is authorised to = send the numbers he sends. A similar trust network is required if we want to have = authenticated CLI in SIP. Currently SIP-T does require exactly the same (physical or secure = VPN) trust network as regular ISUP telephony. Indeed this is probably one of the = main constraining factors that limits whom SIP-T is available to. Your telephone company will be very well positioned to certify that you = have the right to present your telephone number. I would suggest that it will be = your phone company, or a third party acting on their behalf who will do so. Authenticated CLI in SIP may play a very important part in keeping SIP = spamming down. Simon Barber ------=_NextPart_000_02E4_01C04E65.6D5DC860 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_02E4_01C04E65.6D5DC860-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 06:03: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 GAA25409 for ; Tue, 14 Nov 2000 06:03:28 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B76A344393; Tue, 14 Nov 2000 03:09:03 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ion (unknown [211.169.249.227]) by lists.bell-labs.com (Postfix) with ESMTP id B5D7F4433B for ; Tue, 14 Nov 2000 03:05:29 -0500 (EST) Received: from LocalHost ([203.236.3.225]) (authenticated) by ion (8.10.2/8.10.2) with ESMTP id eAE91cJ03607; Tue, 14 Nov 2000 18:01:38 +0900 Message-ID: <037301c04e1a$08b0e1e0$15171796@sktelecom.com> From: =?ks_c_5601-1987?B?vK25rsjx?= To: Cc: "Jonathan Rosenberg" , "Brett Tate" Subject: Re: [SIP] Session-timer with INFO MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01C2_01C04E65.513EAFA0" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 18:01:38 +0900 This is a multi-part message in MIME format. ------=_NextPart_000_01C2_01C04E65.513EAFA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, >First off, I'd like to agree with others here that this is a rehash of = >whats already been discussed, and decided, in the past. If we revisit = >every decision every few months as new people join the lists, we'll = never >make progress. >=20 >The use of INVITE along with the SDP has numerous benefits above just = the >INFO approach. It allows for crash recoveries, it allows for refreshes = of >session state in intermediate devices, such as proxies, and it follows = >the soft-state model present in other similar protocols. Thus, it is = more >general purpose of a solution. Thats been our goal with SIP - to have = >fairly general purpose components that could be used to build a variety = >of different services.=20 I don't want to change the current draft, because it does provide a very mechanism to keep sessions alive, and I agree that it would not take us anywhere if we change things every time someone has a different opinion. My point it is very "heavy", both on the network and the endpoint logic, if the only thing I want is a session heartbeat on the signaling level. Of course, I can personally chose to send INFOs wherever I want, but I don't think that is a good thing to do. And, that way no negotiation of the timeout value, and of which party should send the messages, is possible, why it would be much better to have a standard way on how to do it. Regards, Christer Holmberg Ericsson Finland >I'll agree INFO would eliminate a message, but compared to media, = >signaling is still negligable. We've been through that one umpteen = times, >and the horse is very dead. >=20 >As for the question about how to make sure session timers don't keep = >getting resent if the UAS doesn't support them, thats easy. It would = >include a Require header in the request, listing "timer". If the UAS = >doesn't support session timer, the request is rejected (no session is = >setup either). Now, the UAC knows that the terminating UA doesn't = support >the timer. So, it can either start the session without session = timer at >all by sending a new INVITE with no Supported header and no = >Session-Expires header, give up, or do session timer anyway if the = >proxies want it (Supported header, no Session-Expires header). >=20 >Brett also asks if the UAC can ask to not have the session revived if = the >UAS isn't active. The question really is, who gets to make that = decision? >Is it realy the UAC who should ultimately decide whether a = session >restart is appropriate? Since its really the UAS that needs to = do it, it >seems like it should be its responsibility to decide. >=20 > -Jonathan R. >=20 > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 > > -----Original Message----- > > From: Brett Tate [mailto:brett@broadsoft.com] > > Sent: Tuesday, October 17, 2000 6:57 PM > > To: sip@lists.bell-labs.com > > Subject: Re: [SIP] Session-timer with INFO > > > > > > > While it is true that there are other ways that this could have = been > > solved, > > > it is pretty late in the game to make this kind of a > > change. Especially > > if > > > the only reason for doing so is to avoid the ACK message. > > > > Other reasons include the desire not to revive a > > dead session and to avoid the possibility of a new > > SDP in the 200 response. > > > > > > > > As a side note, we are in the process of creating a new > > version of the > > draft > > > that we hope will be used for working group last call. > > > > Steve, > > > > Can a header or parameter be defined within > > the sip-session-timer to indicate that the sender > > is just trying to extend the Session-Timer and > > check session state, but the sender does NOT > > want the session revived if it is down? The > > reverse of the boolean value could indicate a > > request to revive the session if it is down. > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > >=20 > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip ------=_NextPart_000_01C2_01C04E65.513EAFA0 Content-Type: text/plain Content-Description: Stripped attachment information This Email contained an attachment file named Navidad.exe. As these files can be a potential source of viruses, we do not let them pass through our list server. For any questions please send mail to help@research.bell-labs.com ------=_NextPart_000_01C2_01C04E65.513EAFA0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 06: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 GAA10095 for ; Tue, 14 Nov 2000 06:45:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5F2EB44372; Tue, 14 Nov 2000 05:40:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 30E954436E for ; Tue, 14 Nov 2000 05:39:43 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eAEM8sv14973; Tue, 14 Nov 2000 17:09:06 -0500 (GMT) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eAEBlwP27198; Tue, 14 Nov 2000 17:18:20 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256997.00404A03 ; Tue, 14 Nov 2000 17:12:12 +0530 X-Lotus-FromDomain: HSSBLR From: airoy@hss.hns.com To: "'Neil Deason'" , Sip List Message-ID: <65256997.00404844.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] SIp Torture Tests Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 17:12:07 +0530 Hi.. A possible additon to the torture test list maddr = ipv6address regards, -ashok ----------------- ashok i 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 Nov 14 06:50: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 GAA12079 for ; Tue, 14 Nov 2000 06:50:45 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7AB0A4437E; Tue, 14 Nov 2000 05:43:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id C5A5144349 for ; Tue, 14 Nov 2000 05:42:06 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 14 Nov 2000 11:42:00 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA17234; Tue, 14 Nov 2000 12:40:29 +0100 (BST) Message-ID: <3A1124AE.BEE7E59@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: mranga@nist.gov Cc: Sip List Subject: Re: [SIP] new torture tests References: <3A102B34.3F1FEEBC@ubiquity.net> <3A105D12.D8DE8BF1@nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 14 Nov 2000 11:40:30 +0000 Content-Transfer-Encoding: 7bit "M. Ranganathan" wrote: > > Tbanks for posting these (it has a laxative effect on my parser > :). In particular, I like the fact that you have posted > expected return messages (it would be useful if the previous > list also had such information). Please take note of Jonathan's advice about being liberal though. > I have a couple of questions > on the following header where you have used escape sequences: There have been some considerable discussions on escaping SIP URLs in the past here. > Can the COLON in the sip: of the URI be an escaped sequence? > > Second, you have used %40 in place of the @ at the end of the > user name. Is this legal? If this is legal, then there is no > way for the user to use an escape sequence for part of his or > her name. I think I have been over zealous here in my escaping. So I would suggest changing to the following start line:- INVITE sip:sip%3Auser%40example.com@company.com;other-param=summit SIP/2.0 This re-raises a problem with section 2.1 of bis 02 an example SIP URL is a given as sip:juser@%65xample.com:5060 I think this escaping within a host name is illegal. Any corrections, better suggestions for this test most welcome. 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 Nov 14 06:54: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 GAA13300 for ; Tue, 14 Nov 2000 06:54:31 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C42644392; Tue, 14 Nov 2000 05:43:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id BEFEF44349 for ; Tue, 14 Nov 2000 05:42:37 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 14 Nov 2000 11:42:31 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA17247; Tue, 14 Nov 2000 12:40:57 +0100 (BST) Message-ID: <3A1124C9.86EA9E6A@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , Sip List Subject: Re: [SIP] new torture tests 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, 14 Nov 2000 11:40:57 +0000 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Comments below. > > > The following are 15 new proposed torture test messages > > based on the bis draft. None of them should cause good > > implementations to crash. Recommended responses to the > > illegal messages are given where needed. > > Well, some of your messages have only mild errors in them. Based on the > philosophy of being liberal with what you receive, I would not declare an > entity to have failed the test if it does not generate the specific error > code. Good point, I will include text to this effect. [snip] > > 5) Illegal use of escaped header in Request-URI > > Proxies should strip off the escaped header before proxying on. > > > > INVITE sip:user@company.com?Route=%3Csip:sip.example.com%3E > > SIP/2.0 > > To: sip:user@company.com > > From: sip:caller@university.edu > > Call-ID: 5@10.0.0.1 > > CSeq: 1 INVITE > > Via: SIP/2.0/UDP 135.180.130.133 > > Content-Type: application/sdp > > Content-Length: 174 > > > > v=0 > > o=mhandley 29739 7272939 IN IP4 126.5.4.3 > > s=SIP Call > > t=3149328700 0 > > c=IN IP4 135.180.130.88 > > m=audio 492170 RTP/AVP 0 12 > > m=video 3227 RTP/AVP 31 > > a=rtpmap:31 LPC > > I'm not sure I agree with the behavior here. If the proxy is not > company.com, it may simple forward the request to company.com without > stripping the Route header. I see nothing wrong with that. Glad you think so too because this is what our proxy does. However, bis 02 says in 4.3 "A server which receives a SIP-URL with illegal elements removes them before further processing." So should this text be changed? 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 Nov 14 07:38: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 HAA29457 for ; Tue, 14 Nov 2000 07:38:46 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B794744345; Tue, 14 Nov 2000 06:37:09 -0500 (EST) 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 2A11844340 for ; Tue, 14 Nov 2000 06:36:26 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 14 Nov 2000 12:34:08 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-29) id MAA17502; Tue, 14 Nov 2000 12:34:06 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256997.0044FF56 ; Tue, 14 Nov 2000 12:33:38 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Neil Deason Cc: Sip List Message-ID: <80256997.0043F691.00@marconicomms.com> Subject: Re: [SIP] new torture tests 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, 14 Nov 2000 12:11:38 +0000 I have the following comments/queries (based on bis-02) on the proposed additions for the torture test: Message 2: It is possible to parse this messge correctly even though it is strictly illegal. Message 3: I don't think this message is illegal if reference is made to Appendix C which states: "All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream" Message 4: Where does the spec imply that these characters can be replaced with their escaped values in the context given ? In the case of the @ being replaced with its escape sequence a conflict will occur if a client/proxy wants to use an escaped @ in the user name, a situation described in the recent draft describing registration in a visited domain. Message 5: Where does the spec imply that escaped headers cannot be used in the Reqest-URI ? The BNF for SIP URLs in section 2 gives the following rule: headers = "?" header * ( "&" header ) header = hname "=" hvalue hname = 1*(hnv-unreserved|unreserved|escaped) which will allow escape seqences in SIP URL header fields. Message 13: The Call-ID: and last Via: headers span multiple lines but the LWS at the start of the subsequent lines to indicate line folding (section 6.5 para. 1) is missing. Regards K. Robinson Neil Deason on 13/11/2000 17:56:04 To: Sip List cc: (bcc: Keith Robinson/MAIN/MC1) Subject: [SIP] new torture tests The following are 15 new proposed torture test messages based on the bis draft. None of them should cause good implementations to crash. Recommended responses to the illegal messages are given where needed. I would greatly appreciate any additions/corrections to be made quickly so we can try to get these folded into a new release of the call flows draft before the next bakeoff. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net 1) Illegal enclosing of Request-URI in "<>" Server should respond with 400 + Appropriate Reason Phrase. INVITE SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 1@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 2) Illegal LWS in elements of Request-URI Server should respond with 400 + Appropriate Reason Phrase. INVITE sip:user@company.com; transport=udp SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 2@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 3) Illegal >1 SP between elements of Request URI Server should respond with 400 + Appropriate Reason Phrase. INVITE sip:user@company.com SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 3@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 4) Legal SIP URL in Request URI with escaped characters and parameter. INVITE sip%3Auser%40company.com;other-param=summit SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 4@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 5) Illegal use of escaped header in Request-URI Proxies should strip off the escaped header before proxying on. INVITE sip:user@company.com?Route=%3Csip:sip.example.com%3E SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 5@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 6) Not understood URI in Req-URI but a SIP URL in To. Server should respond 400 + Appropriate Reason Phrase INVITE name:user SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 6@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 7) Legal no LWS between display name and < OPTIONS sip:user@company.com SIP/2.0 To: sip:user@company.com From: "caller" Call-ID: 1234abcd@10.0.0.1 CSeq: 1 OPTIONS Via: SIP/2.0/UDP 135.180.130.133 8) Legal extra LWS between display name and < OPTIONS sip:user@company.com SIP/2.0 To: sip:user@company.com From: "caller" Call-ID: 1234abcd@10.0.0.1 CSeq: 2 OPTIONS Via: SIP/2.0/UDP 135.180.130.133 9) Illegal Non GMT time zone in SIP Date A liberal server should correct this. INVITE sip:user@company.com SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 7@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Expires: Fri, 01 Jan 2010 16:00:00 EST Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 10) Legal message with passed Exipres date. A Server should respond 408 Request Timeout. INVITE sip:user@company.com SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 8@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Expires: Thu, 01 Dec 1994 16:00:00 GMT Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 11) Legal message with zero max forwards Proxies should return 483 Too Many Hops, a UAS responds as for OPTIONS. INVITE sip:user@company.com SIP/2.0 To: sip:user@company.com From: sip:caller@university.edu Call-ID: 9@10.0.0.1 CSeq: 1 INVITE Via: SIP/2.0/UDP 135.180.130.133 Max-Forwards: 0 Content-Type: application/sdp Content-Length: 174 v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 12) Legal REGISTER with SIP URL containing escaped Route header in Contact. REGISTER sip:company.com SIP/2.0 To: sip:user@company.com From: sip:user@company.com Contact: sip:user@host.company.com Call-ID: k345asrl3fdbv@10.0.0.1 CSeq: 1 REGISTER Via: SIP/2.0/UDP 135.180.130.133 Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E 13) Legal but long, includes Token for Call-ID. INVITE sip:user@company.com SIP/2.0 To: "I have a user name of extreme proportion" From: sip:caller@university.edu Call-ID: kl24ahsd546folnyt2vbak9sad98u23naodiunzds09a3bqw0sdfbsk34poouymnae0043nsed09mfkvc74bd0cuwnms05dknw87hjpobd76f CSeq: 1 INVITE My-State: sldkjflzdsfaret0803adgaasd0afds0asdaasd Via: SIP/2.0/UDP sip33.example.com Via: SIP/2.0/UDP sip32.example.com Via: SIP/2.0/UDP sip31.example.com Via: SIP/2.0/UDP sip30.example.com Via: SIP/2.0/UDP sip29.example.com Via: SIP/2.0/UDP sip28.example.com Via: SIP/2.0/UDP sip27.example.com Via: SIP/2.0/UDP sip26.example.com Via: SIP/2.0/UDP sip25.example.com Via: SIP/2.0/UDP sip24.example.com Via: SIP/2.0/UDP sip23.example.com Via: SIP/2.0/UDP sip22.example.com Via: SIP/2.0/UDP sip21.example.com Via: SIP/2.0/UDP sip20.example.com Via: SIP/2.0/UDP sip19.example.com Via: SIP/2.0/UDP sip18.example.com Via: SIP/2.0/UDP sip17.example.com Via: SIP/2.0/UDP sip16.example.com Via: SIP/2.0/UDP sip15.example.com Via: SIP/2.0/UDP sip14.example.com Via: SIP/2.0/UDP sip13.example.com Via: SIP/2.0/UDP sip12.example.com Via: SIP/2.0/UDP sip11.example.com Via: SIP/2.0/UDP sip10.example.com Via: SIP/2.0/UDP sip9.example.com Via: SIP/2.0/UDP sip8.example.com Via: SIP/2.0/UDP sip7.example.com Via: SIP/2.0/UDP sip6.example.com Via: SIP/2.0/UDP sip5.example.com Via: SIP/2.0/UDP sip4.example.com Via: SIP/2.0/UDP sip3.example.com Via: SIP/2.0/UDP sip2.example.com Via: SIP/2.0/UDP sip1.example.com Via: SIP/2.0/UDP host.example.com;received=135.180.130.133;branch=C1C3344E2710000000E299E568E7potato10potato0potato0 Content-Type: application/sdp v=0 o=mhandley 29739 7272939 IN IP4 126.5.4.3 s=SIP Call t=3149328700 0 c=IN IP4 135.180.130.88 m=audio 492170 RTP/AVP 0 12 m=video 3227 RTP/AVP 31 a=rtpmap:31 LPC 14) Illegal, badly mangled message with mutliple To, From, Call-ID and CSeq headers. Server should respond 400 + Appropriate Reason Phrase OPTIONS sip:135.180.130.133 SIP/2.0 Via: SIP/2.0/UDP company.com:5604 From: sip:iuser@company.com To: sip:user@135.180.130.133 Call-ID: 1804928587@company.com CSeq: 1 OPTIONS Expires: 0 0l@company.com To: sip:user@135.180.130.133 Call-ID: 1804928587@company.com CSeq: 1 OPTIONS Contact: sip:host.company.com Expires: 0xpires: 0sip:host.company.com Expires: 0 Contact: sip:host.company.com 15) Legal message with an unusual amount of SDP attributes. INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 56 INVITE Content-Type: application/sdp Content-Length: 320 v=0 o=faxgw1 2890844527 2890844527 IN IP4 iftgw.there.com s=Session SDP c=IN IP4 iftmg.there.com t=0 0 m=image 49172 udptl t38 a=T38FaxVersion:0 a=T38maxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:260 a=T38FaxUdpEC:t38UDPRedundancy _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 14 08:12: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 IAA11062 for ; Tue, 14 Nov 2000 08:12:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 079CC4433D; Tue, 14 Nov 2000 07:12:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 0CD8C44338 for ; Tue, 14 Nov 2000 07:11:17 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 14 Nov 2000 13:11:10 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA01920; Tue, 14 Nov 2000 14:09:41 +0100 (BST) Message-ID: <3A113994.A5383C27@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: Keith Robinson Cc: Sip List Subject: Re: [SIP] new torture tests References: <80256997.0043F691.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 14 Nov 2000 13:09:40 +0000 Content-Transfer-Encoding: 7bit Keith Robinson wrote: > > I have the following comments/queries (based on bis-02) on the proposed > additions for the torture test: Thanks for the comments. > Message 2: > > It is possible to parse this messge correctly even though it is strictly > illegal. If you are clever enough you can parse anything ;) But is a fair point that following the "be liberal on what you accept .." is good and responding 400 to this would be harsh. > Message 3: > > I don't think this message is illegal if reference is made to Appendix C which > states: > > "All linear white space, including folding, has the same semantics as SP. A > recipient MAY replace any linear white space with a single SP before > interpreting the field value > or forwarding the message downstream" Hmm this is a MAY and indeed being liberal and accepting this is highly desirable. Going strictly from section 4.1 I read this as being illegal. Authors, parser implementers care to comment on the matter? > Message 4: > > Where does the spec imply that these characters can be replaced with their > escaped values in the context given ? In the case of the @ being replaced with > its escape sequence a conflict will occur if a client/proxy wants to use an > escaped @ in the user name, a situation described in the recent draft describing > registration in a visited domain. Yeah I got carried away on this one. I intend to change it to : sip:sip%3Auser%40example.com@company.com;other-param=summit > Message 5: > > Where does the spec imply that escaped headers cannot be used in the Reqest-URI > ? The BNF for SIP URLs in section 2 gives the following rule: > > headers = "?" header * ( "&" header ) > header = hname "=" hvalue > hname = 1*(hnv-unreserved|unreserved|escaped) > > which will allow escape seqences in SIP URL header fields. See Table 2 which indicates escaped headers are not allowed in the Req URI. > Message 13: > > The Call-ID: and last Via: headers span multiple lines but the LWS at the start > of the subsequent lines to indicate line folding (section 6.5 para. 1) is > missing. That is an unfortunate effect of my mail client's formatting. 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 Nov 14 08: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 IAA19639 for ; Tue, 14 Nov 2000 08:43:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 716F64433D; Tue, 14 Nov 2000 07:43:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.au.ac.th (home.au.ac.th [202.6.101.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1666E44338 for ; Tue, 14 Nov 2000 07:42:27 -0500 (EST) Received: from pcpop (pc-pop.aunet.au.ac.th [168.120.21.4]) by mail.au.ac.th (Postfix) with SMTP id 205064AD3 for ; Tue, 14 Nov 2000 20:41:26 +0700 (GMT) From: "Voravit H." To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0031_01C04E7B.DC4AAFC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] Call-ID Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 20:45:44 +0700 This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C04E7B.DC4AAFC0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: base64 DQpEZWFyIGFsbA0KDQoJSSBhbSBqdXN0IGEgYmVnaW5uZXIgb2YgU0lQLiBJIGFtIGEgYml0IGNv bmZ1c2UgYWJvdXQgQ2FsbC1JRC4gSQ0KYW0gbm90IHN1cmUgdGhhdCBJIGNsZWFybHkgdW5kZXJz dGFuZCBDYWxsLUlEIG9yIEkgbWlzcyB1bmRlcnN0YW5kaW5nIGl0Lg0KCUlzIHRoaXMgZXhhbXBs ZSBjb3JyZWN0Pw0KDQoJU3VwcG9zZSB0aGF0IEFAQS5DT00gd291bGQgbGlrZSB0byBpbnZpdGUg QkBCLkNPTSB0aGVuIGl0DQpnZW5lcmF0ZXMgYSBJTlZJVEUgcmVxdWVzdCB3aXRoIGEgQ2FsbC1J RCBhcyAxMTFAQS5DT00uDQoJVGhlbiwgaWYgQUBBLkNPTSBhbHNvIHdhbnQgdG8gaW52aXRlIENA Qy5DT00gdGhlbiBpdCBnZW5lcmF0ZXMNCmFub3RoZXIgSU5WSVRFIHJlcXVlc3Qgd2l0aCBhbm90 aGVyIENhbGwtSUQgc3VjaCBhcyAyMjJAQS5DT00uDQoNCglJcyBpdCBjb3JyZWN0Pw0KDQpQT1AN Cg== ------=_NextPart_000_0031_01C04E7B.DC4AAFC0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiwNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAagMAAAAAAABtAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHCwAOABQALQAAAAIAMwEB A5AGAPgFAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAACAAAAENhbGwtSUQAAgFxAAEAAAAWAAAAAcBOQSuq5Y3ZuLpsEdS3JACASOPPawAAAgEdDAEA AAASAAAAU01UUDpQT1BAQVUuQUMuVEgAAAALAAEOAAAAAEAABg4AVhYVQU7AAQIBCg4BAAAAGAAA AAAAAABrDkJELP/TEbckAIBI489rwoAAAAsAHw4BAAAAAgEJEAEAAADCAQAAvgEAAJQCAABMWkZ1 D4MtjgMACgByY3BnODc0AwD4C2BuZzEwNTRPAfcCpANjAgBjaArAc0hldDIRQCBBDxBzoQBwYVVQ QwKAfQqBUnYIkHdrC4BkDkB1zmMAUAsDC7MzMgqiCoHBDvQzMyBEZQrBB0BPCVAUNBQ0AZEgSRVg bRAganVzBUBhIGIUZWcLgG4EkCBvZrEGAElQLhakF1FpBUBpBaBuZhcQZRVgBuB1RQVAQxVxLUlE GGVu2m8FQHMIcBmQdBDgBUAJFrBjbBUxbHkgde8S4ASQFyAAcGQaBhfwBcCdFrBtBAIceAuAZyAZ AB4uFgoEIBuABAAgZXgfFtALUBmQBaEJcGN0P8EVr1N1cHBvGYEbgwBBQEEuQ09NIIp3CGBsHQBs aWsbYSpvHxBuEoB0GZBCQJ5CI5MbgAnwHxEgZwnwDwSQG6AHkRdQSU5WSehURSAJcHEKUBchA/DX G4AXQR0mYQQgMSkAI3T1H0pUJcEsHxAYECNmB0A6cySgdwBwBUAkmENA/kMlbyZ1GvEtMB2xJw8o Ef8uVR0mGzAQ0CjCEUEpPB9rwxkDIS8KUE9QFIUPUAsUJBJBADYwAAALAAGACCAGAAAAAADAAAAA AAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAA AAAAwAAAAAAAAEYAAAAAUoUAAGl5AQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQA AAA5LjAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAA AMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAyACCAGAAAAAADAAAAAAAAARgAAAAA4hQAA AQAAAAEAAAAAAAAACwANgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADA AAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAgg BgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFSACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAA AAMAVYAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAgH4DwEAAAAQAAAAaw5CRCz/0xG3JACA SOPPawIB+g8BAAAAEAAAAGsOQkQs/9MRtyQAgEjjz2sCAfsPAQAAAIIAAAAAAAAAOKG7EAXlEBqh uwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5ET1dTXExv Y2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5w c3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAsAAAAPE5EQkJMSENFR0xJT0FLS0hPREpFS0VD SkNBQUEucG9wQGF1LmFjLnRoPgADAAYQNZ3uogMABxBYAQAAAwAQEAAAAAADABEQAAAAAB4ACBAB AAAAZQAAAERFQVJBTExJQU1KVVNUQUJFR0lOTkVST0ZTSVBJQU1BQklUQ09ORlVTRUFCT1VUQ0FM TC1JRElBTU5PVFNVUkVUSEFUSUNMRUFSTFlVTkRFUlNUQU5EQ0FMTC1JRE9SSU1JU1MAAAAA5C0= ------=_NextPart_000_0031_01C04E7B.DC4AAFC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 08:55:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22719 for ; Tue, 14 Nov 2000 08:55:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 310904434E; Tue, 14 Nov 2000 07:55:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.sipcomm.com (mail.sipcomm.com [64.67.24.21]) by lists.bell-labs.com (Postfix) with ESMTP id 17E2444338; Tue, 14 Nov 2000 07:54:28 -0500 (EST) Received: from cc444799b [24.180.134.92] by mail.sipcomm.com (SMTPD32-6.00) id A4F7D9CD0152; Tue, 14 Nov 2000 08:58:15 -0500 Reply-To: From: "Mohammad Vakil" To: , Subject: RE: [SIP] Call-ID Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001F_01C04E18.81678280" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MS-TNEF-Correlator: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 08:54:32 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C04E18.81678280 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: 7bit There are two scenarios. 1. If A does not want to conference in C rather maintain two seperate calls with B and C, then you're correct, A should generate a different call-Id for C. 2. If A wants to bring C into a conference call on a call going on with B, then it shouldn't generate a new call-id for C. A can invite C with a Also header telling B is also in a call, so C can also establish a signalling relationship with B. Hope this help... > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com] > Sent: Tuesday, November 14, 2000 8:46 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Call-ID > > > Dear all > > I am just a beginner of SIP. I am a bit confuse about Call-ID. I am > not sure that I clearly understand Call-ID or I miss understanding it. > Is this example correct? > > Suppose that A@A.COM would like to invite B@B.COM then it generates > a INVITE request with a Call-ID as 111@A.COM. > Then, if A@A.COM also want to invite C@C.COM then it generates > another INVITE request with another Call-ID such as 222@A.COM. > > Is it correct? > > POP ------=_NextPart_000_001F_01C04E18.81678280 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiANAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHCwAOAAgANgAAAAIAMAEB A5AGACAIAAAkAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAIAAAAQ2FsbC1JRAACAXEAAQAAABsAAAABwE5BK6rljdm4umwR1LckAIBI489r AAAVTSAAAgEdDAEAAAAYAAAAU01UUDpNVkFLSUxAU0lQQ09NTS5DT00ACwABDgAAAABAAAYOAMzz VkJOwAECAQoOAQAAABgAAAAAAAAAUscjbKqw1BGwBwAAhlvJncKAAAALAB8OAQAAAAIBCRABAAAA FAQAABAEAACyBgAATFpGdSXrYhcDAAoAcmNwZzg3NAMA+AtgbmcxMDU0TwH3AqQD4wIAY2gKwHPw ZXQwIAcTAoMAUANUXRC3MhMQEVAPEHMAcGEoVVBDAoMyEEdwcsZxFEEQ11RhaANxAoNuMxRfEscV 1n0KgAjIIGI7CW8yNTUCgAqBdikIkHdrC4BkDkB1Y7sAUAsDYxHyC8QVwGgEkAxlIArAHWB0d28g hwTwCfAKwGlvcy4KooMKhAqAMS4gSWYRUEggZG8HkW5vBUB3mwBwBUB0HeAFoG5mHUEKbh4QIAuA IEMgcvRhdB0xIADAC4ABkCGhuR3DZXAEkCIAHWBjB0DObAQgA/AiECBCHXAbkF0hwCwdsB0wA6B5 CGAnZx1RBaEJcGN0JOAfwHNpFfB1bCSwZwnwI2Rhnx/QBpAhIwVAI8ItSSSw2wIQBcBDH3AeqjIf dSBy+wQgIMFiBRAPECHBIoEd4HcncCD5I8IgAiArsiyiZ35vKxIs4SQkJOUkMCZlbr4nBUAm6ScA B+AoM2kol/cfwCPALsFuGzAjkSHQJCPdJ3BBI/Ad4B0wYQSBHbD+ZSPgKxIkcAQAHXAzAiGh/y0U JOAzESHQMbI0gweQAZHvM+AmcCdhAJBnE6Az1Alw7QtgdB5gAIBoBSAkFR6bPEhvI1Ak8TRRHTBs cJ4uOrAeqgr0M+AzNgFAfxxgAUAU4CBAJgER4wvwNB4gAzAO9D1wFCQxNiDqLT7STwUQZwuAB0AF 0P8HkBOAJuA+0x6mPLQ8gQsTwTy2aS0xNDQBQDPgODE4MAFADNBCc2IgWkYDYToDMAySYgLRM6k3 EXAtM2BtC4BANrGpKpAuYjPBLQtgYh6AUQWgbSBbImFsIMA6+0TfRepdKRYMMBQwBlECMA46RCUV wApQc2RheeEk4E5vdmUG0CIxQnCHJOAB0EMAIDg6ND6w/EFNSSYVwEcQRCxHz0ZxMUkrdWJqJgFN iltT1ElQSQBDKENEOuxA/+884jwEDvY9FDMUQB60DvT6M0SwRDNQBcAj0TrrAZHnH4AdcEaQanU2 cCdhRdD/P1EnASzQH6BRsR9xWKJZMd8u4SDyWPAdYQbgdQVAUgV7WkUgMnMIcDoCIgBYgWPCbFcR bHkgdRuQBJD/NnEkolIULNAFwFiQR5AEEX9eWCsSJDAellhTKqE6MmVueFiwC1Alpz9Xj1BwcAZw HnBdRUFAQS5D3E9NIGAmkzPgax2hNLL5MhNCQDjwZYIulibmNGFBH4BOVklURTfBca9KwSBRMpRf BmEEIDFq4PdlVGEqHSFuJOAGkGU3NIP7IHYx9kAo8GdfaGQgMSIi/2jfMqJwNV8GXRAQ0GqiExEP axxhS1rjYw8KUE9QF1T4HrMYsQB4EB4AQhABAAAALAAAADxOREJCTEhDRUdMSU9BS0tIT0RKRUtF Q0pDQUFBLnBvcEBhdS5hYy50aD4ACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKA CCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9 bgEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsADYAIIAYAAAAAAMAA AAAAAABGAAAAAIKFAAABAAAACwARgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADABKACCAG AAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAG4AIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAA AwAcgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAB6ACCAGAAAAAADAAAAAAAAARgAAAAAY hQAAAAAAAAIB+A8BAAAAEAAAAFLHI2yqsNQRsAcAAIZbyZ0CAfoPAQAAABAAAABSxyNsqrDUEbAH AACGW8mdAgH7DwEAAACCAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAA AE5JVEH5v7gBAKoAN9luAAAAQzpcV0lORE9XU1xMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBE YXRhXE1pY3Jvc29mdFxPdXRsb29rXG1haWxib3gucHN0AAAAAwD+DwUAAAADAA00/TcAAAIBfwAB AAAAMgAAADxORUJCTEFBSEZDTUhLRkRIR0RDTkVFRUNDQUFBLm12YWtpbEBzaXBjb21tLmNvbT4A AAADAAYQ3jWJCwMABxBWAwAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAFRIRVJFQVJFVFdP U0NFTkFSSU9TMUlGQURPRVNOT1RXQU5UVE9DT05GRVJFTkNFSU5DUkFUSEVSTUFJTlRBSU5UV09T RVBFUkFURUNBTExTV0lUSEJBTkRDLFRIRU5ZT1VSRUMAAAAASxY= ------=_NextPart_000_001F_01C04E18.81678280-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 09:18: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 JAA00319 for ; Tue, 14 Nov 2000 09:18:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 887174434E; Tue, 14 Nov 2000 08:18:21 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from agni.wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by lists.bell-labs.com (Postfix) with ESMTP id 5E3F04433D for ; Tue, 14 Nov 2000 08:17:45 -0500 (EST) Received: from vayu.wipinfo.soft.net (vayu [192.168.200.170]) by agni.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id TAA12363 for ; Tue, 14 Nov 2000 19:41:44 +0500 (GMT) Received: from platinum.mail.wipro.com ([192.168.223.18]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id TAA26569 for ; Tue, 14 Nov 2000 19:45:07 +0500 (GMT) Received: from wipro.com ([192.168.205.52]) by platinum.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA3248 for ; Tue, 14 Nov 2000 19:46:54 +0530 Message-ID: <39E86B92.28FF3625@wipro.com> From: "Rakesh Jain" X-Mailer: Mozilla 4.7 [en] (Win98; 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] query on multicast conference ... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 14 Oct 2000 19:50:02 +0530 Content-Transfer-Encoding: 7bit Hi, I am having one query regarding bahavior of the SIP user agent. Let terminal A,B and C are in a multicast conference. Terminal D wants to join the conference so it sends an INVITE messege to terminal A with same session description. Can some one please tell me what could be the behavior of terminal A, 1. will it accept the INVITE and send Ack to terminal D. OR 2. Reject the INVITE and send RE - INVITE to all terminals A, B and D. Thanks in advance... rakesh jain _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 09:20: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 JAA01167 for ; Tue, 14 Nov 2000 09:20:31 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D21724434E; Tue, 14 Nov 2000 08:19:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from fepE.post.tele.dk (fepE.post.tele.dk [195.41.46.137]) by lists.bell-labs.com (Postfix) with ESMTP id B0C0C4435B for ; Tue, 14 Nov 2000 08:18:32 -0500 (EST) Received: from dynamicsoft.com ([195.249.119.96]) by fepE.post.tele.dk (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001114141825.ULQK29032.fepE.post.tele.dk@dynamicsoft.com>; Tue, 14 Nov 2000 15:18:25 +0100 Message-ID: <3A1149CA.194FB857@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Keith Robinson , Sip List Subject: Re: [SIP] new torture tests References: <80256997.0043F691.00@marconicomms.com> <3A113994.A5383C27@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 14 Nov 2000 15:18:50 +0100 Content-Transfer-Encoding: 7bit Neil Deason wrote: > > Keith Robinson wrote: > > > > Message 2: > > > > It is possible to parse this messge correctly even though it is strictly > > illegal. > > If you are clever enough you can parse anything ;) > But is a fair point that following the "be liberal on what > you accept .." is good and responding 400 to this would be > harsh. I don't know about that. I believe it is the case that URLs can *never* contain unencoded space characters. If this is true then the test seems very reasonable. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 09: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 JAA02141 for ; Tue, 14 Nov 2000 09:23:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AAEEC44364; Tue, 14 Nov 2000 08:19:20 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from fepE.post.tele.dk (fepE.post.tele.dk [195.41.46.137]) by lists.bell-labs.com (Postfix) with ESMTP id 4CD0E4433D for ; Tue, 14 Nov 2000 08:18:17 -0500 (EST) Received: from dynamicsoft.com ([195.249.119.96]) by fepE.post.tele.dk (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001114141809.ULPB29032.fepE.post.tele.dk@dynamicsoft.com>; Tue, 14 Nov 2000 15:18:09 +0100 Message-ID: <3A1149B9.8AFD903B@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: Sip List Subject: Re: [SIP] new torture tests References: <3A102B34.3F1FEEBC@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 14 Nov 2000 15:18:33 +0100 Content-Transfer-Encoding: 7bit Neil Deason wrote: > > The following are 15 new proposed torture test messages > based on the bis draft. None of them should cause good > implementations to crash. Recommended responses to the > illegal messages are given where needed. > > I would greatly appreciate any additions/corrections to be > made quickly so we can try to get these folded into a new > release of the call flows draft before the next bakeoff. I've included some below. > > 12) Legal REGISTER with SIP URL containing escaped Route header > in Contact. > > REGISTER sip:company.com SIP/2.0 > To: sip:user@company.com > From: sip:user@company.com > Contact: sip:user@host.company.com > Call-ID: k345asrl3fdbv@10.0.0.1 > CSeq: 1 REGISTER > Via: SIP/2.0/UDP 135.180.130.133 > Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E Actually, this request is illegal. The bis-02 draft says about the Contact header (section 6.14): Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, semicolon, or question mark. The SIP URI in the Contact header includes a '?' char, and so the Contact value needs to be in addr-spec form: Contact: Had the "extra stuff" been a parameter instead of a header it would be parsed as a Contact parameter rather than a url-parameter. This would be fine from the parsers point of view but is a common source of error nonetheless. In fact, this type of error is common enough to make it worth exercising explicitly in the tests. I propose instead adding the following tests... 12a) Legal REGISTER with SIP URL containing escaped Route header in Contact. REGISTER sip:company.com SIP/2.0 To: sip:user@company.com From: sip:user@company.com Contact: sip:user@host.company.com Call-ID: k345asrl3fdbv@10.0.0.1 CSeq: 1 REGISTER Via: SIP/2.0/UDP 135.180.130.133 Contact: 12b) Illegal REGISTER with Contact containing header. Server should respond with 400 + Appropriate Reason Phrase. REGISTER sip:company.com SIP/2.0 To: sip:user@company.com From: sip:user@company.com Contact: sip:user@host.company.com Call-ID: k345asrl3fdbv@10.0.0.1 CSeq: 1 REGISTER Via: SIP/2.0/UDP 135.180.130.133 Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E 12c) Legal but probably doesn't mean what was intended. The 'user' parameter should be interpreted as being a contact-param and not a url-parameter. The request should succeed but a subsequent retrieval of the registration must NOT include "user=phone" as a url-parameter. REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:watson@bell-tel.com To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 2 REGISTER Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone 12d) Same as 12c but with this Contact header: Contact: ;user=phone Other candidates... 16) Legal: display name in From/To/Contact contains multiple tokens and is unqouted: INVITE sip:t.watson@ieee.org SIP/2.0 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell To: T. Watson Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE 17) Illegal: unquoted display name in From/To/Contact contains non-token characters. Server should respond with 400 + Appropriate Reason Phrase. INVITE sip:t.watson@ieee.org SIP/2.0 Via: SIP/2.0/UDP c.bell-tel.com From: Bell, Alexander To: Watson, Thomas Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE 18) Unknown (higher) protocol version in request line. Server should respond with 400 + Appropriate Reason Phrase. INVITE sip:t.watson@ieee.org SIP/7.0 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell To: T. Watson Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE 19) Legal leading zero in protocol version numbers INVITE sip:t.watson@ieee.org SIP/02.00 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell To: T. Watson Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE Cheers, Anders _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 09:55:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10826 for ; Tue, 14 Nov 2000 09:55:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D8BE4433D; Tue, 14 Nov 2000 08:55:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 78DF044338 for ; Tue, 14 Nov 2000 08:54:10 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 14 Nov 2000 08:54:03 -0600 (CST) From: Billy Biggs To: Mohammad Vakil Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Call-ID Message-ID: <20001114085403.A27737@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from mvakil@sipcomm.com on Tue, Nov 14, 2000 at 08:54:32AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 14 Nov 2000 08:54:03 -0600 Mohammad Vakil (mvakil@sipcomm.com): > 2. If A wants to bring C into a conference call on a call going on > with B, then it shouldn't generate a new call-id for C. A can invite C > with a Also header telling B is also in a call, so C can also > establish a signalling relationship with B. Sorry, but the use of the Also header has been deprecated. I doubt you will find anyone who implements this or ever intends to. It has been deemed a "bad idea". -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 10:49:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28848 for ; Tue, 14 Nov 2000 10:49:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2236C4433D; Tue, 14 Nov 2000 09:49:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DF05F44338 for ; Tue, 14 Nov 2000 09:48:45 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA14383; Tue, 14 Nov 2000 10:50:56 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2YZMC>; Tue, 14 Nov 2000 10:47:01 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , "Schmidlin, David" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Redirect VS Proxy Server 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, 14 Nov 2000 10:46:57 -0500 I believe the difference is fundmentally one of control. You use a proxy when you want to control processing of the call from the point you receive it, and forward. A proxy can see the provisional and final responses to the request. It can record route so that it sees whats going on during the call. A redirect server, however, hands off control to the device that sent it the INVITE. It will never see the final response to the request, and not be contacted again for the remainder of the call. Its a one-shot deal. As such, redirect servers are really good for high volume, lookup style transactions. They can almost be considered a form of database query, albeit a SIP specific one. Proxies are generally needed for services and more complex routing problems. -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: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Monday, November 13, 2000 8:38 PM > To: Schmidlin, David > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Redirect VS Proxy Server > > > Schmidlin, David (david.schmidlin@intel.com): > > > Why/Where would you use a redirect server over a proxy > server and vice > > versa? > > If you were a web server, when would you send a redirect and when > would you proxy? It's the same answer. > > Redirect servers are cheap to code, for one. But these are logical > roles not separate entities, so your question should be more specific. > > In general you proxy a message when you are providing some > additional > feature rather than simply performing a lookup. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 12:35:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27374 for ; Tue, 14 Nov 2000 12:35:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D65EF4433D; Tue, 14 Nov 2000 11:35:08 -0500 (EST) 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 5089C44338 for ; Tue, 14 Nov 2000 11:35:00 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 14 Nov 2000 17:00:08 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-29) id QAA01889; Tue, 14 Nov 2000 16:15:07 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256997.00593E5C ; Tue, 14 Nov 2000 16:14:46 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Anders Kristensen Cc: Neil Deason , Sip List Message-ID: <80256997.00593BC8.00@marconicomms.com> Subject: Re: [SIP] new torture tests 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, 14 Nov 2000 16:14:27 +0000 I am not suggesting that it is legal to put unencoded spaces in the Request-URI; I realise this is strictly illegal. The point I am making is that if a parser knows it has got the Request-URI because it is the text that lies between the Method and SIP-Version elements it can remove all unencoded spaces precisely because of the rule that URIs cannot contain unencoded white spaces. If a parser can do this without jeopardising the rest of the lexical analysis then it would be harsh to determine that it is in error if it does not return a 400 response but goes onto handle the request in a normal and correct manner. The type of parser that MUST return an error is one that is checking the output of proxies/agents to make sure they do format messages strictly, i.e., checking message generation as opposed to message parsing. Anders Kristensen on 14/11/2000 14:18:50 To: Neil Deason cc: Keith Robinson/MAIN/MC1@MCMAIN, Sip List Subject: Re: [SIP] new torture tests Neil Deason wrote: > > Keith Robinson wrote: > > > > Message 2: > > > > It is possible to parse this messge correctly even though it is strictly > > illegal. > > If you are clever enough you can parse anything ;) > But is a fair point that following the "be liberal on what > you accept .." is good and responding 400 to this would be > harsh. I don't know about that. I believe it is the case that URLs can *never* contain unencoded space characters. If this is true then the test seems very reasonable. -- 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 Tue Nov 14 16:24: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 QAA05539 for ; Tue, 14 Nov 2000 16:24:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5423D44338; Tue, 14 Nov 2000 15:24:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lists.bell-labs.com (Postfix) with ESMTP id 29B8244336 for ; Tue, 14 Nov 2000 15:23:39 -0500 (EST) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 11C4917DF; Tue, 14 Nov 2000 15:01:32 -0600 (CST) Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 9C5CE153E for ; Tue, 14 Nov 2000 15:01:32 -0600 (CST) Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Tue, 14 Nov 2000 15:01:31 -0600 Message-ID: <202F03744BDCD31194270000F803CA9E770111@cxoexc2.cxo.dec.com> From: "Maddux, Michel" To: sip@lists.bell-labs.com Cc: "Lawhorn, Tom" , "Byrne, Sam" , "Hurlbert, John" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP - H.323 - INVITE - No media line. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 15:00:29 -0600 In constructing a gateway connecting Sip to 323, the process of signalling a call and then negotiating channels, for a Sip caller to 323 callee, is relatively straightforward. Only one temporizing step is required, and that is to not provide an RTCP address in opening channels from gateway (actually Sip) to 323 callee. The reverse case, of implementing 323 caller to Sip callee, is not so straightforward. Signalling is tractable, but media channel negotiation is murky. Two models occur: 1) When 323 calls, wait until it opens first media channel. Then issue the INVITE, noting only a media line of that media type but with a phony port. When Sip replies (200 OK presumed), complete the 323 media channel being negotiated, giving it the Sip's media port. Then negotiate the reverse channel with 323, saving its port, which is then transmitted to Sip via an ACK with a message body correcting the 323 media port. If the 323 caller then opens another media channel, repeat the above process via re-INVITE, and continue to do so as long as 323 requests media channels. 2) Depend upon language from the 2543 spec, particularly section B.4 and the ACK section, which state that an INVITE could be sent with NO media lines, upon receipt of which the Sip callee would respond with a list of its supported media (AND presumably providing a port for each of these). In this scenario, an INVITE devoid of media would be issued immediately on receipt of call from the 323 caller. The resulting 200 OK media list would then be used to negotiate the media channels with the 323 caller, and would be returned in final form in the message body of the ACK. [It is possible that this model would devolve to the first model since it is not known when the 323 caller is through opening channels. Should a mid-call media change be initiated by the 323 caller, the re-INVITE process would need be used, anyway.] We are interested in a recommendation as to how to do this. Are either of the above models viable, or does a better model exist? What is the spec status of section B.4? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 16:36:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08173 for ; Tue, 14 Nov 2000 16:36:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92BCD4433D; Tue, 14 Nov 2000 15:36:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lists.bell-labs.com (Postfix) with ESMTP id 33FA944338 for ; Tue, 14 Nov 2000 15:35:34 -0500 (EST) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id 8477E2E8D; Tue, 14 Nov 2000 16:35:27 -0500 (EST) Received: from exchou-gh01.cca.cpqcorp.net (exchou-gh01.cca.cpqcorp.net [16.110.248.201]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 33DA52D9C; Tue, 14 Nov 2000 16:35:27 -0500 (EST) Received: by exchou-gh01.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Tue, 14 Nov 2000 15:35:26 -0600 Message-ID: <202F03744BDCD31194270000F803CA9E770112@cxoexc2.cxo.dec.com> From: "Maddux, Michel" To: "'Billy Biggs'" , Mohammad Vakil Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Call-ID MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 14 Nov 2000 15:35:14 -0600 What is the best method then, if Also is deprecated? thanks. /m. Michel A. Maddux Senior IP Architect -----Original Message----- From: Billy Biggs [mailto:Billy_Biggs@3com.com] Sent: Tuesday, November 14, 2000 7:54 AM To: Mohammad Vakil Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Call-ID Mohammad Vakil (mvakil@sipcomm.com): > 2. If A wants to bring C into a conference call on a call going on > with B, then it shouldn't generate a new call-id for C. A can invite C > with a Also header telling B is also in a call, so C can also > establish a signalling relationship with B. Sorry, but the use of the Also header has been deprecated. I doubt you will find anyone who implements this or ever intends to. It has been deemed a "bad idea". -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 16: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 QAA09250 for ; Tue, 14 Nov 2000 16:41:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E15744341; Tue, 14 Nov 2000 15:41:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 7E3264433D for ; Tue, 14 Nov 2000 15:40:57 -0500 (EST) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G41AE400.VT7; Tue, 14 Nov 2000 13:30:04 -0800 Message-ID: <3A11B160.9AADB401@vovida.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: "Maddux Michel" Cc: sip@lists.bell-labs.com, "Lawhorn Tom" , "Byrne Sam" , "Hurlbert John" Subject: Re: [SIP] SIP - H.323 - INVITE - No media line. References: <202F03744BDCD31194270000F803CA9E770111@cxoexc2.cxo.dec.com> Content-Type: multipart/alternative; boundary="------------76858BE3241BF9867A9908A9" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 13:40:48 -0800 --------------76858BE3241BF9867A9908A9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The annswers to most of your question in developing such a gateway you can find in: http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt Have fun. :) "Maddux, Michel" wrote: > In constructing a gateway connecting Sip to 323, the process of signalling a > call and then negotiating channels, for a Sip caller to 323 callee, is > relatively straightforward. Only one temporizing step is required, and that > is to not provide an RTCP address in opening channels from gateway (actually > Sip) to 323 callee. > > The reverse case, of implementing 323 caller to Sip callee, is not so > straightforward. Signalling is tractable, but media channel negotiation is > murky. Two models occur: > > 1) When 323 calls, wait until it opens first media channel. Then issue the > INVITE, noting only a media line of that media type but with a phony port. > When Sip replies (200 OK presumed), complete the 323 media channel being > negotiated, giving it the Sip's media port. Then negotiate the reverse > channel with 323, saving its port, which is then transmitted to Sip via an > ACK with a message body correcting the 323 media port. If the 323 caller > then opens another media channel, repeat the above process via re-INVITE, > and continue to do so as long as 323 requests media channels. > > 2) Depend upon language from the 2543 spec, particularly section B.4 and the > ACK section, which state that an INVITE could be sent with NO media lines, > upon receipt of which the Sip callee would respond with a list of its > supported media (AND presumably providing a port for each of these). In this > scenario, an INVITE devoid of media would be issued immediately on receipt > of call from the 323 caller. The resulting 200 OK media list would then be > used to negotiate the media channels with the 323 caller, and would be > returned in final form in the message body of the ACK. [It is possible that > this model would devolve to the first model since it is not known when the > 323 caller is through opening channels. Should a mid-call media change be > initiated by the 323 caller, the re-INVITE process would need be used, > anyway.] > > We are interested in a recommendation as to how to do this. Are either of > the above models viable, or does a better model exist? What is the spec > status of section B.4? > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.com --------------76858BE3241BF9867A9908A9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The annswers to most of your question in developing such a gateway you
can find in:

http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt

Have fun. :)

"Maddux, Michel" wrote:

In constructing a gateway connecting Sip to 323, the process of signalling a
call and then negotiating channels, for a Sip caller to 323 callee, is
relatively straightforward. Only one temporizing step is required, and that
is to not provide an RTCP address in opening channels from gateway (actually
Sip) to 323 callee.

The reverse case, of implementing 323 caller to Sip callee, is not so
straightforward. Signalling is tractable, but media channel negotiation is
murky. Two models occur:

1) When 323 calls, wait until it opens first media channel. Then issue the
INVITE, noting only a media line of that media type but with a phony port.
When Sip replies (200 OK presumed), complete the 323 media channel being
negotiated, giving it the Sip's media port. Then negotiate the reverse
channel with 323, saving its port, which is then transmitted to Sip via an
ACK with a message body correcting the 323 media port. If the 323 caller
then opens another media channel, repeat the above process via re-INVITE,
and continue to do so as long as 323 requests media channels.

2) Depend upon language from the 2543 spec, particularly section B.4 and the
ACK section, which state that an INVITE could be sent with NO media lines,
upon receipt of which the Sip callee would respond with a list of its
supported media (AND presumably providing a port for each of these). In this
scenario, an INVITE devoid of media would be issued immediately on receipt
of call from the 323 caller. The resulting 200 OK media list would then be
used to negotiate the media channels with the 323 caller, and would be
returned in final form in the message body of the ACK. [It is possible that
this model would devolve to the first model since it is not known when the
323 caller is through opening channels. Should a mid-call media change be
initiated by the 323 caller, the re-INVITE process would need be used,
anyway.]

We are interested in a recommendation as to how to do this. Are either of
the above models viable, or does a better model exist? What is the spec
status of section B.4?

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

-- 
Vladislav Zubarev        mailto:vladis@vovida.com
Software Engineer   
Vovida Networks, Inc.    http://www.vovida.com
  --------------76858BE3241BF9867A9908A9-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 16: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 QAA11338 for ; Tue, 14 Nov 2000 16:50:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 43E6044346; Tue, 14 Nov 2000 15:50:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 47A3344345 for ; Tue, 14 Nov 2000 15:49:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA18471; Tue, 14 Nov 2000 16:51:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y5G1>; Tue, 14 Nov 2000 16:47:42 -0500 Message-ID: From: Jonathan Rosenberg To: "'Rakesh Jain'" , sip@lists.bell-labs.com Subject: RE: [SIP] query on multicast conference ... 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, 14 Nov 2000 16:47:35 -0500 > -----Original Message----- > From: Rakesh Jain [mailto:rakesh.jain@wipro.com] > Sent: Saturday, October 14, 2000 10:20 AM > To: sip@lists.bell-labs.com > Subject: [SIP] query on multicast conference ... > > > > Hi, > I am having one query regarding bahavior of the SIP user agent. > Let terminal A,B and C are in a multicast conference. > Terminal D wants to join the conference so it sends an INVITE > messege to > terminal A with same session description. Thats not what you would do for a large scale multicast conference. There is a lot of confusion these days around conferences, largely because there are several different models for how they operate. Some of these models work with SIP today, and others require extensions. I am preparing an I-D, due out the end of this week, that goes over the various types of multiparty conferences you can have, how they work, how they differ, etc. Keep posted. -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 Nov 14 17:05: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 RAA14589 for ; Tue, 14 Nov 2000 17:05:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DEE914433D; Tue, 14 Nov 2000 16:05:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id 33B1644336 for ; Tue, 14 Nov 2000 16:04:47 -0500 (EST) Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 14:09:05 -0800 Message-ID: From: Sekhar Banerjee To: Sip List MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] What am I doing wrong ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 14:09:03 -0800 Hi SIP Experts, Here is a question that I have about a certain call flow that I am trying to implement. Please look at the call flows and let me know what is wrong in this picture. A Proxy B C INVITE------------> INVITE----------> <--------- 100 Trying <--------- 180 Ringing <----------------- 180 Ringing CANCEL ----------> <----------- 200 OK <----------- 487 INVITE -----------------------------> <------------------------------ 100 Trying <------------------------------ 180 Ringing <----------------- 180 Ringing <------------------------------ 200 OK <----------------- 200 OK What I have noticed with the devices that I am testing this call flow is that somehow they dont like the 180/200 OK that come in from C. Is there a reason for this ? I would love to know this. Thanks a lot Sekhar Banerjee _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 17:14: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 RAA17265 for ; Tue, 14 Nov 2000 17:14:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B104B4433D; Tue, 14 Nov 2000 16:14:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 5C33344338 for ; Tue, 14 Nov 2000 16:13:21 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 14 Nov 2000 16:12:46 -0600 (CST) From: Billy Biggs To: "Maddux, Michel" Cc: Mohammad Vakil , sip@lists.bell-labs.com Subject: Re: [SIP] Call-ID Message-ID: <20001114161246.A28093@div8.net> References: <202F03744BDCD31194270000F803CA9E770112@cxoexc2.cxo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <202F03744BDCD31194270000F803CA9E770112@cxoexc2.cxo.dec.com>; from Michel.Maddux@COMPAQ.com on Tue, Nov 14, 2000 at 03:35:14PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 16:12:46 -0600 Maddux, Michel (Michel.Maddux@COMPAQ.com): > What is the best method then, if Also is deprecated? thanks. /m. The scenario asked about was a distributed conference: > > 2. If A wants to bring C into a conference call on a call going on > > with B, then it shouldn't generate a new call-id for C. A can invite > > C with a Also header telling B is also in a call, so C can also > > establish a signalling relationship with B. This form of conferencing, where each participant has a distinct signalling relationship with each other, is difficult to manage. It seems that people are currently just implementing simpler forms of conferences using MCUs, 3-Way calling, and handoff/transfer using REFER. Also was originally defined in the sip-cc-01 call control draft, which is long expired. It was not continued due to the complexity of the draft, the many unresolved issues, and the dangerous overloading of INVITE/BYE. Some further investigation was done by some folks at Dialogic in the dmcs draft, but after discussion at the IETF, the 4th Bakeoff, and on the mailing list, it was decided that further call control extensions be defined more explicitly using new methods where applicable. At least that was my understanding. This philosophy is outlined in the Call Control Framework draft, draft-campbell-sip-cc-framework-01.txt -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 17:45: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 RAA25132 for ; Tue, 14 Nov 2000 17:45:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 60D5E44338; Tue, 14 Nov 2000 16:45:08 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 1E27144336 for ; Tue, 14 Nov 2000 16:44:10 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Nov 14 17:43:53 EST 2000 Received: by lists.bell-labs.com (Postfix) id 724BD44380; Tue, 14 Nov 2000 17:30:43 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 068824437D for ; Tue, 14 Nov 2000 17:30:43 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA06263; Tue, 14 Nov 2000 16:30:40 -0600 Cc: Sip List Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA06249; Tue, 14 Nov 2000 16:30:38 -0600 Message-ID: <3A11BD0D.A69F8FFF@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sekhar Banerjee Original-CC: Sip List Subject: Re: [SIP] What am I doing wrong ? 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, 14 Nov 2000 16:30:37 -0600 Content-Transfer-Encoding: 7bit Sekhar Banerjee wrote: > > Hi SIP Experts, > Here is a question that I have about a certain call flow that I am > trying to implement. Please look at the call flows and let me know what is > wrong in this picture. > > A Proxy B C > > INVITE------------> > INVITE----------> > <--------- 100 Trying > <--------- 180 Ringing > <----------------- 180 Ringing > CANCEL ----------> > <----------- 200 OK > <----------- 487 > > INVITE -----------------------------> > <------------------------------ 100 > Trying > <------------------------------ 180 > Ringing > <----------------- 180 Ringing > <------------------------------ 200 > OK > <----------------- 200 OK > > What I have noticed with the devices that I am testing this call > flow is that somehow they dont like the 180/200 OK that come in from C. Is > there a reason for this ? I would love to know this. There is no reason why A should reject a 180/200 OK from C; since it never got a final response from B, a call leg has not yet been established at A. On getting a 200 OK from C, a call leg should be established at A. However, I do see a bug in your call flow; note your call flow: A Proxy B C INV--------> INV------> <--------100 <--------180 <---------180 CANCEL-----> <-----------200 OK <-----------487 INV---------------------> In your call flow, your proxy starts a second INVITE to C; it never sends an ACK to B; it should. Logically, B's INVITE is still pending and it will continue re-transmitting 487 until ACK'ed or maximum response retransmission limit has reached (which is 7 for an INVITE, if I am not mistaken). I also assume that the 200 OK from B->Proxy is for Cancel (you do not indicate this in your call flow). If this is not a correct assumption and the 200 OK is for the INVITE, and since you want to CANCEL the transaction, you should ACK the 200 OK and then send a BYE. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 18:03:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29215 for ; Tue, 14 Nov 2000 18:03:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EDF2B4433D; Tue, 14 Nov 2000 17:03:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id 992D244338 for ; Tue, 14 Nov 2000 17:02:55 -0500 (EST) Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 15:07:18 -0800 Message-ID: From: Sekhar Banerjee To: "'Vijay Gurbani'" Cc: Sip List Subject: RE: [SIP] What am I doing wrong ? 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, 14 Nov 2000 15:07:17 -0800 Hi Vijay, Sekhar Banerjee wrote: > > Hi SIP Experts, > Here is a question that I have about a certain call flow that I am > trying to implement. Please look at the call flows and let me know what is > wrong in this picture. > > A Proxy B C > > INVITE------------> > INVITE----------> > <--------- 100 Trying > <--------- 180 Ringing > <----------------- 180 Ringing > CANCEL ----------> > <----------- 200 OK > <----------- 487 > > INVITE -----------------------------> > <------------------------------ 100 > Trying > <------------------------------ 180 > Ringing > <----------------- 180 Ringing > <------------------------------ 200 > OK > <----------------- 200 OK > > What I have noticed with the devices that I am testing this call > flow is that somehow they dont like the 180/200 OK that come in from C. Is > there a reason for this ? I would love to know this. >Vijay wrote : >There is no reason why A should reject a 180/200 OK from C; since it never >got a final response from B, a call leg has not yet been established at A. >On getting a 200 OK from C, a call leg should be established at A. >However, I do see a bug in your call flow; note your call flow: >A Proxy B C >INV--------> > INV------> > <--------100 > <--------180 ><---------180 > CANCEL-----> > <-----------200 OK > <-----------487 > INV---------------------> >In your call flow, your proxy starts a second INVITE to C; it never sends an >ACK to B; it should. Logically, B's INVITE is still pending and it will >continue re-transmitting 487 until ACK'ed or maximum response retransmission >limit has reached (which is 7 for an INVITE, if I am not mistaken). Well .... that was something that I forgot to put in the diagram. I do finish the INVITE transaction with the ACK. >I also assume that the 200 OK from B->Proxy is for Cancel (you do not indicate >this in your call flow). If this is not a correct assumption and the 200 OK is >for the INVITE, and since you want to CANCEL the transaction, you should ACK >the 200 OK and then send a BYE. Yes ... the 200 OK is for the cancel. But my concern is with the tags that get attached with the responses comming in from the end devices. Could that be the problem. I mean just because the first 180 ringing had a different tag in the To field than in the second 180 ringing. Is that significant enough ? Thanks Sekhar _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 18: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 SAA09375 for ; Tue, 14 Nov 2000 18:43:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E0A454433D; Tue, 14 Nov 2000 17:43:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 5C9BC44336 for ; Tue, 14 Nov 2000 17:42:08 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 14 Nov 2000 17:15:37 -0600 (CST) From: Billy Biggs To: Sekhar Banerjee Cc: "'Vijay Gurbani'" , Sip List Subject: Re: [SIP] What am I doing wrong ? Message-ID: <20001114171537.A28219@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from SBanerjee@lboard.com on Tue, Nov 14, 2000 at 03:07:17PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 17:15:37 -0600 Sekhar Banerjee (SBanerjee@lboard.com): > But my concern is with the tags that get attached with the > responses comming in from the end devices. Could that be the > problem. I mean just because the first 180 ringing had a different > tag in the To field than in the second 180 ringing. Is that > significant enough ? The UA should have no problem seeing different tags on responses. If the UA can't handle it, it is broken. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 19:13:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15923 for ; Tue, 14 Nov 2000 19:13:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 41D7344338; Tue, 14 Nov 2000 18:13:08 -0500 (EST) 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 CF2BF44336 for ; Tue, 14 Nov 2000 18:12:07 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue Nov 14 19:10:02 EST 2000 Received: by lists.bell-labs.com (Postfix) id D440B44380; Tue, 14 Nov 2000 18:56:52 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id B555E4437D for ; Tue, 14 Nov 2000 18:56:50 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA05968; Tue, 14 Nov 2000 17:56:48 -0600 Cc: Sip List Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA05960; Tue, 14 Nov 2000 17:56:47 -0600 Message-ID: <3A11D13E.DA27A35A@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sekhar Banerjee Original-CC: Sip List Subject: Re: [SIP] What am I doing wrong ? 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, 14 Nov 2000 17:56:46 -0600 Content-Transfer-Encoding: 7bit Sekhar Banerjee wrote: [...] > Yes ... the 200 OK is for the cancel. > > But my concern is with the tags that get attached with the responses > comming in from the end devices. Could that be the problem. I mean just > because the first 180 ringing had a different tag in the To field than in > the second 180 ringing. Is that significant enough ? Not enough to make the UAC misbehave; the tags on the provisional responses from different UASs will be different. As I said earlier, the call leg has not yet been established until a final response arrives at the UAC. The 200 OK from C should be accepted by A. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 20:09: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 UAA28920 for ; Tue, 14 Nov 2000 20:09:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC65944338; Tue, 14 Nov 2000 19:09:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6223344336 for ; Tue, 14 Nov 2000 19:08:26 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA20155; Tue, 14 Nov 2000 20:10:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y5RH>; Tue, 14 Nov 2000 20:06:45 -0500 Message-ID: From: Igor Slepchin To: "'Maddux, Michel'" , sip@lists.bell-labs.com Cc: "Lawhorn, Tom" , "Byrne, Sam" , "Hurlbert, John" Subject: RE: [SIP] SIP - H.323 - INVITE - No media line. 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, 14 Nov 2000 20:06:42 -0500 > 1) When 323 calls, wait until it opens first media channel. > Then issue the > INVITE, noting only a media line of that media type but with > a phony port. > When Sip replies (200 OK presumed), complete the 323 media > channel being > negotiated, giving it the Sip's media port. Then negotiate the reverse > channel with 323, saving its port, which is then transmitted > to Sip via an > ACK with a message body correcting the 323 media port. This is illegal in SIP (see section 4.2.1 in 2543bis). You should use re-INVITE if you want to modify the session offered in INVITE request. Thank you, 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 Tue Nov 14 20:26:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02711 for ; Tue, 14 Nov 2000 20:26:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3F0344338; Tue, 14 Nov 2000 19:26:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id 0292144336 for ; Tue, 14 Nov 2000 19:25:32 -0500 (EST) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G41KSF00.UVT; Tue, 14 Nov 2000 17:14:39 -0800 Message-ID: <3A11E604.ECB1259B@vovida.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: Igor Slepchin Cc: "'Maddux Michel'" , sip@lists.bell-labs.com, "Lawhorn Tom" , "Byrne Sam" , "Hurlbert John" Subject: Re: [SIP] SIP - H.323 - INVITE - No media line. References: Content-Type: multipart/alternative; boundary="------------E51163373267F2F75774436D" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 14 Nov 2000 17:25:24 -0800 --------------E51163373267F2F75774436D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Again, call scenarios with different issues resolving (like this) can be found in the following document: http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt Thanx. Igor Slepchin wrote: > > 1) When 323 calls, wait until it opens first media channel. > > Then issue the > > INVITE, noting only a media line of that media type but with > > a phony port. > > When Sip replies (200 OK presumed), complete the 323 media > > channel being > > negotiated, giving it the Sip's media port. Then negotiate the reverse > > channel with 323, saving its port, which is then transmitted > > to Sip via an > > ACK with a message body correcting the 323 media port. > > This is illegal in SIP (see section 4.2.1 in 2543bis). You should use > re-INVITE if you want to modify the session offered in INVITE request. > > Thank you, > Igor Slepchin > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.com --------------E51163373267F2F75774436D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Again, call scenarios with different issues resolving (like this) can
be found in the following document:

http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt

Thanx.

Igor Slepchin wrote:

> 1) When 323 calls, wait until it opens first media channel.
> Then issue the
> INVITE, noting only a media line of that media type but with
> a phony port.
> When Sip replies (200 OK presumed), complete the 323 media
> channel being
> negotiated, giving it the Sip's media port. Then negotiate the reverse
> channel with 323, saving its port, which is then transmitted
> to Sip via an
> ACK with a message body correcting the 323 media port.

This is illegal in SIP (see section 4.2.1 in 2543bis). You should use
re-INVITE if you want to modify the session offered in INVITE request.

Thank you,
Igor Slepchin

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

-- 
Vladislav Zubarev        mailto:vladis@vovida.com
Software Engineer   
Vovida Networks, Inc.    http://www.vovida.com
  --------------E51163373267F2F75774436D-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 14 22: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 WAA29528 for ; Tue, 14 Nov 2000 22:25:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0DD844338; Tue, 14 Nov 2000 21:25:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 7549544336 for ; Tue, 14 Nov 2000 21:24:41 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 19:25:38 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Anders Kristensen'" , "'Neil Deason'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] new torture tests 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, 14 Nov 2000 19:25:36 -0800 > > 12d) Same as 12c but with this Contact header: > > Contact: ;user=phone > Can we add a torture test with a more taxing telephone subscriber Request-URI. It is important that proxies and clients process these correctly (even if they just ignore them or return a 404 Not Found). INVITE sip:+1-972-555-2222;phone-context=name%40domain;new=user?%22Route:%20X%40Y%3 bZ=W%22@gw1.wcom.com;user=phone SIP/2.0 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 Tue Nov 14 23:30:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15608 for ; Tue, 14 Nov 2000 23:30:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 808ED44338; Tue, 14 Nov 2000 22:30:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 2FBD544336 for ; Tue, 14 Nov 2000 22:29:16 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Nov 2000 20:30:13 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "Fairlie-Cuninghame, Robert" , "'Anders Kristensen'" , "'Neil Deason'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] new torture tests 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, 14 Nov 2000 20:30:13 -0800 > > > > 12d) Same as 12c but with this Contact header: > > > > Contact: ;user=phone > > > Can we add a torture test with a more taxing telephone subscriber > Request-URI. It is important that proxies and clients process these > correctly (even if they just ignore them or return a 404 Not Found). > > INVITE > sip:+1-972-555-2222;phone-context=name%40domain;new=user?%22Ro > ute:%20X%40Y%3 > bZ=W%22@gw1.wcom.com;user=phone SIP/2.0 > Actually, I think the colon after Route needs to be quoted as well. Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 06:45:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03261 for ; Wed, 15 Nov 2000 06:45:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 784704434C; Wed, 15 Nov 2000 05:45:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web10308.mail.yahoo.com (web10308.mail.yahoo.com [216.136.130.86]) by lists.bell-labs.com (Postfix) with SMTP id B899D44336 for ; Wed, 15 Nov 2000 05:44:28 -0500 (EST) Message-ID: <20001115114422.33087.qmail@web10308.mail.yahoo.com> Received: from [203.197.179.177] by web10308.mail.yahoo.com; Wed, 15 Nov 2000 03:44:22 PST From: james jack To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Consultation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 03:44:22 -0800 (PST) Dear All: I want to consult one question, RFC2543 bis 02 as for Digest Authentication referenced RFC2617, On RFC2617, where it is listed as the following: challenge = "Digest" digest-challenge digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] ) domain = "domain" "=" <"> URI ( 1*SP URI ) <"> URI = Request-URI nonce = "nonce" "=" nonce-value nonce-value = quoted-string opaque = "opaque" "=" quoted-string stale = "stale" "=" ( "true" | "false" ) algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | token ) qop-options = "qop" "=" <"> 1#qop-value <"> qop-value = "auth" | "auth-int" | token I have no idea on MD5-sess, could anyone give me some information on MD5-sess, I will try to find the detailed description on MD5-see. Thanks in advance! Best regards! Yours: Jim __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 08:14:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16543 for ; Wed, 15 Nov 2000 08:14:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C4F044354; Wed, 15 Nov 2000 07:14:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 922D544336 for ; Wed, 15 Nov 2000 07:13:05 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 15 Nov 2000 13:12:59 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA16432; Wed, 15 Nov 2000 14:11:28 +0100 (BST) From: "Jo Hornsby" To: Message-ID: <00a701c04f05$907dfae0$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] Old Torture Tests Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 13:11:28 -0000 Content-Transfer-Encoding: 7bit Hello. I think that "test7.txt" is wrong, the text says: This request message contains a new method, NEWMETHOD. A proxy should forward this using the same retransmission rules as INVITE. A UAS should reject it with an error, and list the available methods in the response. My thinking is that the retransmission rules should be based on the nominal retransmission rules; i.e., the ones in 10.4.1, which describe behaviour for requests other than INVITE and ACK. Should "test10.txt" now be deprecated, since multiplemessages per datagram has been removed? (This was done, wasn't it; I didn't dream it? (:&) Ditto "test18.txt"? Cheers, - 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 Wed Nov 15 08:50: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 IAA28976 for ; Wed, 15 Nov 2000 08:50:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9A48744349; Wed, 15 Nov 2000 07:50:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by lists.bell-labs.com (Postfix) with ESMTP id A73034436E for ; Tue, 14 Nov 2000 09:58:29 -0500 (EST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA09141; Tue, 14 Nov 2000 07:58:22 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA05349; Tue, 14 Nov 2000 07:58:22 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14865.24862.232817.774106@thomasm-u1.cisco.com> To: "Tom Tang" Cc: Subject: [SIP] SIP End-2-End Security 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: Tue, 14 Nov 2000 07:58:22 -0800 (PST) Content-Transfer-Encoding: 7bit You need to be careful about what you mean by "end to end". Proxy-routed e-2-e traffic cannot use TLS. Only an application layer protocol such as PGP can do that, and you still probably want to use hopwise crypto to protect the outer headers from tampering and snooping. If you're talking about hopwise crypto -- which may lead to an end to end security association with the two UA's -- TLS and IPsec are the usual suspects. TLS doesn't work for UDP, so IPsec is somewhat more general. Mike Tom Tang writes: > > Hello : > > I am wondering what mechanisms companies are planning to > deploy for SIP security. I've been hearing PGP and TLS > mainly, but I didn't see any postings for extensions to > either protocols. Please tell me if I've skipped over some > draft. Thanks. > > - Tom Tang > > > Tom Tang > IP Unity > 1575 McCandless Drive > Milpitas, CA 95035 > (408) 957-0800 x154 (w) > (408) 957-0823 (f) > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 15 08:51: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 IAA29651 for ; Wed, 15 Nov 2000 08:51:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 558DC4435B; Wed, 15 Nov 2000 07:50:23 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from lornadoon.akc.com (lornadoon.donet.com [205.133.113.5]) by lists.bell-labs.com (Postfix) with ESMTP id 6E4BD44336 for ; Wed, 15 Nov 2000 07:46:21 -0500 (EST) Received: from cc89326b (backup.akc.com [24.6.239.68]) by lornadoon.akc.com (8.9.3/8.9.3) with SMTP id IAA26413; Wed, 15 Nov 2000 08:44:15 -0500 Message-ID: <001701c04f02$2180ec40$44ef0618@union1.nj.home.com> Reply-To: "Al Costanzo" From: "Al Costanzo" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] draft-costanzo-dns-gl-03.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 07:46:52 -0500 Content-Transfer-Encoding: 7bit Hello, I am Al Costanzo and I wrote ID , it was suggested to me to to bring it to the attention of this WG for consideration. If you are interested in the draft, I would be more than willing with the working group to modify it to allow it to do what you need. Regards, Al Costanzo ---Exerpt of the email I received: You may already be aware of it, your I-D on Definition of the DNS GL Resource Record is of high interest to the IP communications community. Especially, if you have any additional ideas how to use this service for 911 calls from IP SIP phones. Suggest to bring it to attention of the IETF SIP WG list - sip@lists.bell-labs.com, SIP Forum list - SIP Forum Discussion - discussion@sipforum.org ----------------------------------------------------- Best Internet Services - Web Hosting $10.00 a month http://www.akc.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 Nov 15 09: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 JAA10144 for ; Wed, 15 Nov 2000 09:18:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 61BFB44366; Wed, 15 Nov 2000 08:18:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E87F544365 for ; Wed, 15 Nov 2000 08:17:45 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA22877; Wed, 15 Nov 2000 09:19:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y61Z>; Wed, 15 Nov 2000 09:15:48 -0500 Message-ID: From: Jonathan Rosenberg To: "'Jo Hornsby'" , sip@lists.bell-labs.com Subject: RE: [SIP] Old Torture Tests MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 09:15:45 -0500 > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Wednesday, November 15, 2000 8:11 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Old Torture Tests > > > Hello. > > I think that "test7.txt" is wrong, the text says: > > This request message contains a new method, NEWMETHOD. > A proxy should forward this using the same retransmission > rules as INVITE. A UAS should reject it with an error, > and list the available methods in the response. > > My thinking is that the retransmission rules should be based on > the nominal retransmission rules; i.e., the ones in 10.4.1, > which describe behaviour for requests other than INVITE and ACK. Correct. This needs to be fixed. > > Should "test10.txt" now be deprecated, since multiplemessages > per datagram has been removed? (This was done, wasn't it; I > didn't dream it? (:&) Ditto "test18.txt"? Correct. In fact, the correct behavior now for test18 would be to reject that request. Now that multiple messages per UDP datagram is deprecated, the correct behavior for when the body is longer than the Content-Length is to reject the request. -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 Nov 15 09:22: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 JAA11908 for ; Wed, 15 Nov 2000 09:22:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AFC4D4436B; Wed, 15 Nov 2000 08:20:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 537CB44365 for ; Wed, 15 Nov 2000 08:19:26 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA22861; Wed, 15 Nov 2000 09:17:55 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y61V>; Wed, 15 Nov 2000 09:13:58 -0500 Message-ID: From: Jonathan Rosenberg To: "'Vijay Gurbani'" , Sekhar Banerjee Cc: Sip List Subject: RE: [SIP] What am I doing wrong ? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 09:13:56 -0500 > -----Original Message----- > From: Vijay Gurbani [mailto:vkg@lucent.com] > Sent: Tuesday, November 14, 2000 6:57 PM > To: Sekhar Banerjee > Cc: Sip List > Subject: Re: [SIP] What am I doing wrong ? > > > Sekhar Banerjee wrote: > [...] > > Yes ... the 200 OK is for the cancel. > > > > But my concern is with the tags that get attached with > the responses > > comming in from the end devices. Could that be the problem. > I mean just > > because the first 180 ringing had a different tag in the To > field than in > > the second 180 ringing. Is that significant enough ? > > Not enough to make the UAC misbehave; the tags on the > provisional responses > from different UASs will be different. As I said earlier, > the call leg has > not yet been established until a final response arrives at > the UAC. The 200 > OK from C should be accepted by A. Well, the UAC shouldn't misbehave, but that doesn't mean it isn't misbehaving. This case (of getting different tags in the provisionals than in the final) is probably not well tested in many implementations. Its probably worth adding a torture test case for this. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 10:15:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05879 for ; Wed, 15 Nov 2000 10:15:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D3A004434D; Wed, 15 Nov 2000 09:15:07 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 6562F44336 for ; Wed, 15 Nov 2000 09:14:09 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Nov 15 10:12:14 EST 2000 Received: by lists.bell-labs.com (Postfix) id 8A00344380; Wed, 15 Nov 2000 09:59:04 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 2EA3E4437D for ; Wed, 15 Nov 2000 09:59:04 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA04743; Wed, 15 Nov 2000 08:59:01 -0600 Cc: Sip List Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA04719; Wed, 15 Nov 2000 08:59:00 -0600 Message-ID: <3A12A4B1.9BD8640C@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Original-CC: Sip List Subject: Re: [SIP] What am I doing wrong ? 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, 15 Nov 2000 08:58:57 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > Well, the UAC shouldn't misbehave, but that doesn't mean it isn't > misbehaving. This case (of getting different tags in the provisionals than > in the final) is probably not well tested in many implementations. > > Its probably worth adding a torture test case for this. Sure; I can write one up. Who is maintaining the "Torture Document?" I can send it to him/her directly. - vijay - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 10:18: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 KAA06940 for ; Wed, 15 Nov 2000 10:18:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6890F4436F; Wed, 15 Nov 2000 09:18:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 3BA2F44365 for ; Wed, 15 Nov 2000 09:17:25 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA03743; Wed, 15 Nov 2000 10:17:16 -0500 (EST) Message-ID: <3A12A8FC.4F2D7BAB@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Gurbani Cc: Jonathan Rosenberg , Sip List Subject: Re: [SIP] What am I doing wrong ? References: <3A12A4B1.9BD8640C@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 10:17:16 -0500 Content-Transfer-Encoding: 7bit Vijay Gurbani wrote: > > Jonathan Rosenberg wrote: > [...] > > Well, the UAC shouldn't misbehave, but that doesn't mean it isn't > > misbehaving. This case (of getting different tags in the provisionals than > > in the final) is probably not well tested in many implementations. > > > > Its probably worth adding a torture test case for this. > > Sure; I can write one up. Who is maintaining the "Torture Document?" I > can send it to him/her directly. > I'm keeping the torture files. Once the discussion has died down, I'd appreciate if somebody could send them to me so that I can add them to the bakeoff web page. -- 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 Nov 15 10:22: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 KAA08478 for ; Wed, 15 Nov 2000 10:22:23 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B59594437E; Wed, 15 Nov 2000 09:19:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 0890D44365 for ; Wed, 15 Nov 2000 09:18:47 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA03820 for ; Wed, 15 Nov 2000 10:18:40 -0500 (EST) Message-ID: <3A12A950.EDD1763D@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP web page outages today Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 10:18:40 -0500 Content-Transfer-Encoding: 7bit We're moving computer equipment today, so it is possible that the SIP web pages will be temporarily unavailable. There is no need to send me email about this. -- 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 Nov 15 10:33: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 KAA12310 for ; Wed, 15 Nov 2000 10:33:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F47644373; Wed, 15 Nov 2000 09:33:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 038D944360 for ; Wed, 15 Nov 2000 09:32:03 -0500 (EST) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 15 Nov 2000 15:31:56 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA20553; Wed, 15 Nov 2000 16:30:26 +0100 (BST) Message-ID: <3A12AC11.32236AEE@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: Vijay Gurbani Cc: Sip List Subject: Re: [SIP] What am I doing wrong ? References: <3A12A4B1.9BD8640C@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 15:30:25 +0000 Content-Transfer-Encoding: 7bit Vijay Gurbani wrote: > > Jonathan Rosenberg wrote: > [...] > > Well, the UAC shouldn't misbehave, but that doesn't mean it isn't > > misbehaving. This case (of getting different tags in the provisionals than > > in the final) is probably not well tested in many implementations. > > > > Its probably worth adding a torture test case for this. > > Sure; I can write one up. Who is maintaining the "Torture Document?" I > can send it to him/her directly. I am collecting together new torture tests for submission to the call flows work and Henning's web site. They need to be out in time for the next bakeoff. 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 Nov 15 11:07:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24837 for ; Wed, 15 Nov 2000 11:07:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 434134434B; Wed, 15 Nov 2000 10:07:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B4DDC44336 for ; Wed, 15 Nov 2000 10:06:36 -0500 (EST) Received: from dynamicsoft.com ([212.120.151.166]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA24473; Wed, 15 Nov 2000 11:08:45 -0500 (EST) Message-ID: <3A12B434.EE04C0E7@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jainsip@sun.com Cc: sip@lists.bell-labs.com, discussion@sipforum.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] JAIN SIP - Issues to be resolved Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 16:05:09 +0000 Content-Transfer-Encoding: 7bit All, Now that the JAIN SIP API is using interfaces instead of classes for messages and headers, the implementations of these interfaces will have their own parsing mechanisms. Currently the API set methods throw IllegalArgumentExceptions if the user attempts to use a null or zero-length parameter. The question now is should an implementation throw an IllegalArgument if it doesn't like the value, or should we create an exception for anything implementation-specific. An example of this is the AcceptLanguageHeader. The API allows any String that is not null or zero-length be used as the language range. Obviously an implementation should be stricter on the content of this String. The reason we are so tolerant of parameter values was that the headers were originally defined as classes in the API, and we did not want to include a full SIP parser in the API. However, now that interfaces are used, an alternative would be to simply extend the definition of an illegal argument - for example, the implementation should throw an IllegalArgumentException if the language range does not conform to the RFC. (Of course testing this would be another matter entirely!) Another separate issue is - what should an implementation do if receives something from the network that it cannot parse correctly? Should the JAIN SIP application be made aware of it, or should the implementation automatically send back the appropriate response to the network? This obviously depends on whether the implementation is lazy-parsing or parsing the entire message up front, and we have to accomodate both scenarios (this is after all one of the main reasons we moved from classes to interfaces) Your opinions are of course welcomed. Regards, Chris Harris _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 11:25:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02442 for ; Wed, 15 Nov 2000 11:25:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8DE144350; Wed, 15 Nov 2000 10:25:08 -0500 (EST) 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 6EAF944336 for ; Wed, 15 Nov 2000 10:24:43 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G4200J01QVKT2@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 15 Nov 2000 16:23:45 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G4200IEVQVK4U@firewall.mcit.com>; Wed, 15 Nov 2000 16:23:44 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0G4200I01QRGW5@dgismtp03.wcomnet.com>; Wed, 15 Nov 2000 16:21:16 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G4200I01QREVS@dgismtp03.wcomnet.com>; Wed, 15 Nov 2000 16:21:16 +0000 (GMT) Received: from wcom.com ([166.46.20.159]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G4200GMXQQJNN@dgismtp03.wcomnet.com>; Wed, 15 Nov 2000 16:20:45 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] SIP ringback tone To: "Fairlie-Cuninghame, Robert" Cc: "'sip@lists.bell-labs.com'" Message-id: <3A12B914.BB2ACD17@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 10:25:57 -0600 Content-Transfer-Encoding: 7bit Robert, In actual implementations, often a 183 will actually be sent during ringing, due to the fact that often a gateway will be unable to determine definitively if ringing or some other information is being sent in-band. My concern is that this reading will cause gateway vendors to assume that ringing is taking place, send a 180 with SDP. Then, the User Agent may also assume that ringing is taking place, not play the early media stream to the user. (The bis spec currently only says SHOULD.) If the call then receives treatment, the user will then have not idea why the call failed. I agree that a User Agent should not have to know that it is talking to a gateway to the PSTN. What it does need to know is that media described in the SDP of a 183 response MUST be played to the user, or the final outcome of a call may not be known. (Since 183 is a new response code, there aren't any backwards compatibility issues here, are there?) Thanks, Alan. "Fairlie-Cuninghame, Robert" wrote: > The way the spec is written at the moment (see Section 7.1 - it changed > recently), a UAC should be able to accept any 1xx response (other than 100) > with SDP as indicating early media. eg 183, 182, 181 or 180. Obviously they > must have different meanings or there is no reason to have the different > response codes (COMET aside). Both the expired 183 draft (explicitly) and > the bis-02 draft (inferred) say that 183 indicates call progress events > _other_ than user alerting (eg "queued message", "please wait, verifying" or > "enter pin number" voice messages) --- yet the mechanism is the same for 180 > and 183. [I just think it should be made clearer in the 183 description.] > > I don't understand your point about requiring support for two mechanisms and > that it "masks whether I'm going to the PSTN or another SIP endpoint > identified by a telephone number". How so? And more importantly, why is this > necessary ? > > In fact I would say the opposite is true. A SIP client that is not PSTN > centric and doesn't bother with early media playback should not have to know > that 183 is actually ringback on a PSTN SIP client. The client should simply > know that a received 180 indicates user alerting, 182 is queued and 183 is > some other call progress event. > > Regards, > > Robert. > > -- My opinions are my own. I tried selling them once but everybody > seems to already have one. -- > > -----Original Message----- > > From: David Shrader [mailto:dshrader@master-consultant.com] > > Sent: Monday, November 13, 2000 9:54 PM > > To: Fairlie-Cuninghame, Robert > > Cc: SIP List > > Subject: Re: [SIP] SIP ringback tone > > > > > > Robert, > > > > I don't agree that 183 with SDP should only be a call > > progress message. It > > is a perfectly reasonable usage to support ringback. This is > > especially > > necessary when interworking with the PSTN where ringback is delivered > > inband. If you implement a system that works with the PSTN, I think we > > shouldn't require it to support two modes of operation. It > > seems reasonable > > that the use of 183 masks whether I'm going to the PSTN or another SIP > > endpoint identified by a telephone number and allows the > > person or network > > being called to provide whatever inband indication it chooses. > > > > David > > > > ---------------------------- > > David Shrader > > Master Consultant, Inc. > > dshrader@master-consultant.com > > http://www.EyeForTheFuture.com > > > > > From: "Fairlie-Cuninghame, Robert" > > > Date: Mon, 13 Nov 2000 03:33:35 -0800 > > > To: "'Henry Sinnreich'" > > > Cc: "'sip@lists.bell-labs.com'" > > > Subject: RE: [SIP] SIP ringback tone > > > > > > Henry, > > > > > > Innovative ringback greetings definitely seem like a case > > for an early media > > > to me. > > > > > > As an aside, many people still seem to erroroneously think > > that 183 Session > > > Progress should be used for early-media ring-back. 180 > > Ringing with SDP > > > should be used for ringback purposes, 183 with SDP should > > only be used for > > > call progress messages (ie, not alerting the user). I still > > think this needs > > > to be made clearer in the spec! > > > > > > Cheers, > > > > > > Robert. > > > > > > -- My opinions are my own. I tried selling them once but everybody > > > seems to already have one. -- > > > > > >> -----Original Message----- > > >> From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > > >> Sent: Monday, November 13, 2000 6:18 AM > > >> To: adam.roach@ericsson.com; IETF SIP (E-mail) > > >> Subject: [SIP] SIP ringback tone > > >> > > >> > > >> The draft on "Ringback tones in SIP-Based Telephony" shows > > >> impressive work > > >> on preserving legacy country specific ring back tones. I > > >> wonder if we would > > >> not be better of by adding a > > >> > > >> SIP Ringback Tone > > >> ================= > > >> > > >> With some optional fields where service providers could > > add innovative > > >> greetings. > > >> > > >> Henry > > >> > > >> Henry Sinnreich > > >> WorldCom > > >> 400 International Parkway, > > >> Richardson, Texas, 75081 > > >> > > >> > > >> > > >> _______________________________________________ > > >> SIP mailing list > > >> SIP@lists.bell-labs.com > > >> http://lists.bell-labs.com/mailman/listinfo/sip > > >> > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 15 11:28:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03634 for ; Wed, 15 Nov 2000 11:28:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B12C44384; Wed, 15 Nov 2000 10:28:08 -0500 (EST) 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 5A39944382 for ; Wed, 15 Nov 2000 10:27:40 -0500 (EST) 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 RAA14985; Wed, 15 Nov 2000 17:27:08 +0100 (MET) Received: by klatt.axis.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Nov 2000 17:26:24 +0100 Message-ID: <151F3D2AE9F0D3119E480004ACB8EA37018692DB@cluster01.axis.se> From: Peter Kjellerstedt To: "'Neil Deason'" Cc: Sip List Subject: RE: [SIP] new torture tests MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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, 15 Nov 2000 17:29:01 +0100 > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: 13 November 2000 18:56 > To: Sip List > Subject: [SIP] new torture tests > > The following are 15 new proposed torture test messages > based on the bis draft. None of them should cause good > implementations to crash. Recommended responses to the > illegal messages are given where needed. > > I would greatly appreciate any additions/corrections to be > made quickly so we can try to get these folded into a new > release of the call flows draft before the next bakeoff. > > Cheers, > Neil. One test I realized is missing when I was at the last bake-off is one that tests the following kind of To/From header: To: sip:pkj@axis.com ;tag=123456789@example.com and makes sure the tag does not end up as a URL parameter. I had not considered this legal before I got one like that sent to me (and studied the 2543 document for some time...) //Peter _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 13:13: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 NAA11439 for ; Wed, 15 Nov 2000 13:13:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA6154435E; Wed, 15 Nov 2000 12:13:07 -0500 (EST) 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 1C19944336 for ; Wed, 15 Nov 2000 12:12:35 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id MAA25210; Wed, 15 Nov 2000 12:13:14 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Nov 2000 12:05:56 -0600 Message-ID: From: "Culpepper, Bert" To: "'sip@lists.bell-labs.com'" Cc: Alan Johnston , "Fairlie-Cuninghame, Robert" Subject: RE: [SIP] SIP ringback tone MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 12:05:54 -0600 I think that Alan and Robert are "saying" the same thing. My understanding is that a UAC, upon receipt of a 180 without SDP, indicates to the user that the callee is being alerted. It can use whatever method it desires such as a pop-up message, playing an audible ringback tone, etc. to indicate this to the local user. If the 180 included a SDP, the UAC can present the media stream or not. However, I believe the UAC should cease its local indication (if any) upon receipt of a 183. The UAS sends a 183 (with SDP) to indicate that it will be sending early media (typically some call progress message). The local ringing indication should cease at the UAC so that the user can "hear" the early media (disposition of the call). If the UAS wishes to provide ringback tone it can send a 180 with SDP. A 183 with SDP could be used too but why not use the Ringing response for ringback instead of a Session Progress response for ringback. As Robert writes, a 180 indicates a specific state. The 180 with local alerting indication at the UAC minimizes network, UAC, and UAS resources during the setup phase and allows the UAC to locally indicate remote alerting however it likes. If tone characteristics are present in a header of the 180 the UAC can "customize" its local alerting as Adam's Ringback I-D supports. Regards, Bert -----Original Message----- From: Alan Johnston [mailto:alan.johnston@wcom.com] Sent: Wednesday, November 15, 2000 11:26 AM To: Fairlie-Cuninghame, Robert Cc: 'sip@lists.bell-labs.com' Subject: Re: [SIP] SIP ringback tone Robert, In actual implementations, often a 183 will actually be sent during ringing, due to the fact that often a gateway will be unable to determine definitively if ringing or some other information is being sent in-band. My concern is that this reading will cause gateway vendors to assume that ringing is taking place, send a 180 with SDP. Then, the User Agent may also assume that ringing is taking place, not play the early media stream to the user. (The bis spec currently only says SHOULD.) If the call then receives treatment, the user will then have not idea why the call failed. I agree that a User Agent should not have to know that it is talking to a gateway to the PSTN. What it does need to know is that media described in the SDP of a 183 response MUST be played to the user, or the final outcome of a call may not be known. (Since 183 is a new response code, there aren't any backwards compatibility issues here, are there?) Thanks, Alan. "Fairlie-Cuninghame, Robert" wrote: > The way the spec is written at the moment (see Section 7.1 - it changed > recently), a UAC should be able to accept any 1xx response (other than 100) > with SDP as indicating early media. eg 183, 182, 181 or 180. Obviously they > must have different meanings or there is no reason to have the different > response codes (COMET aside). Both the expired 183 draft (explicitly) and > the bis-02 draft (inferred) say that 183 indicates call progress events > _other_ than user alerting (eg "queued message", "please wait, verifying" or > "enter pin number" voice messages) --- yet the mechanism is the same for 180 > and 183. [I just think it should be made clearer in the 183 description.] > > I don't understand your point about requiring support for two mechanisms and > that it "masks whether I'm going to the PSTN or another SIP endpoint > identified by a telephone number". How so? And more importantly, why is this > necessary ? > > In fact I would say the opposite is true. A SIP client that is not PSTN > centric and doesn't bother with early media playback should not have to know > that 183 is actually ringback on a PSTN SIP client. The client should simply > know that a received 180 indicates user alerting, 182 is queued and 183 is > some other call progress event. > > Regards, > > Robert. > > -- My opinions are my own. I tried selling them once but everybody > seems to already have one. -- > > -----Original Message----- > > From: David Shrader [mailto:dshrader@master-consultant.com] > > Sent: Monday, November 13, 2000 9:54 PM > > To: Fairlie-Cuninghame, Robert > > Cc: SIP List > > Subject: Re: [SIP] SIP ringback tone > > > > > > Robert, > > > > I don't agree that 183 with SDP should only be a call > > progress message. It > > is a perfectly reasonable usage to support ringback. This is > > especially > > necessary when interworking with the PSTN where ringback is delivered > > inband. If you implement a system that works with the PSTN, I think we > > shouldn't require it to support two modes of operation. It > > seems reasonable > > that the use of 183 masks whether I'm going to the PSTN or another SIP > > endpoint identified by a telephone number and allows the > > person or network > > being called to provide whatever inband indication it chooses. > > > > David > > > > ---------------------------- > > David Shrader > > Master Consultant, Inc. > > dshrader@master-consultant.com > > http://www.EyeForTheFuture.com > > > > > From: "Fairlie-Cuninghame, Robert" > > > Date: Mon, 13 Nov 2000 03:33:35 -0800 > > > To: "'Henry Sinnreich'" > > > Cc: "'sip@lists.bell-labs.com'" > > > Subject: RE: [SIP] SIP ringback tone > > > > > > Henry, > > > > > > Innovative ringback greetings definitely seem like a case > > for an early media > > > to me. > > > > > > As an aside, many people still seem to erroroneously think > > that 183 Session > > > Progress should be used for early-media ring-back. 180 > > Ringing with SDP > > > should be used for ringback purposes, 183 with SDP should > > only be used for > > > call progress messages (ie, not alerting the user). I still > > think this needs > > > to be made clearer in the spec! > > > > > > Cheers, > > > > > > Robert. > > > > > > -- My opinions are my own. I tried selling them once but everybody > > > seems to already have one. -- > > > > > >> -----Original Message----- > > >> From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > > >> Sent: Monday, November 13, 2000 6:18 AM > > >> To: adam.roach@ericsson.com; IETF SIP (E-mail) > > >> Subject: [SIP] SIP ringback tone > > >> > > >> > > >> The draft on "Ringback tones in SIP-Based Telephony" shows > > >> impressive work > > >> on preserving legacy country specific ring back tones. I > > >> wonder if we would > > >> not be better of by adding a > > >> > > >> SIP Ringback Tone > > >> ================= > > >> > > >> With some optional fields where service providers could > > add innovative > > >> greetings. > > >> > > >> Henry > > >> > > >> Henry Sinnreich > > >> WorldCom > > >> 400 International Parkway, > > >> Richardson, Texas, 75081 > > >> > > >> > > >> > > >> _______________________________________________ > > >> SIP mailing list > > >> SIP@lists.bell-labs.com > > >> http://lists.bell-labs.com/mailman/listinfo/sip > > >> > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 15 15:24: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 PAA06328 for ; Wed, 15 Nov 2000 15:24:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 27FB044364; Wed, 15 Nov 2000 14:24:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from newman.frascone.com (frascone.com [216.62.83.25]) by lists.bell-labs.com (Postfix) with ESMTP id 88AA244336 for ; Wed, 15 Nov 2000 14:23:30 -0500 (EST) Received: (from chaos@localhost) by newman.frascone.com (8.9.3/8.9.3) id OAA07963; Wed, 15 Nov 2000 14:22:50 -0600 From: David Frascone To: sip@lists.bell-labs.com Message-ID: <20001115142250.B7933@newman.frascone.com> Mail-Followup-To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i X-encrypt-payload: no Subject: [SIP] Sip Grammars out there? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 14:22:50 -0600 Has anyone out there written a sip parser in yacc/bison? I'm trying to find a free grammar for it if anyone has. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 16:42: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 QAA08475 for ; Wed, 15 Nov 2000 16:42:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0D09044362; Wed, 15 Nov 2000 15:42:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id DF3D644336 for ; Wed, 15 Nov 2000 15:41:32 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id QAA18822; Wed, 15 Nov 2000 16:36:25 -0500 (EST) Message-ID: <3A1302BE.D3E44779@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: David Frascone Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Sip Grammars out there? References: <20001115142250.B7933@newman.frascone.com> Content-Type: multipart/alternative; boundary="------------53D8C37F6C1A1A5AB4F43976" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 16:40:14 -0500 --------------53D8C37F6C1A1A5AB4F43976 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Not yacc but antlr (output language is java). Stay tuned... I will put one out in a matter of 2 weeks (I am documenting it and getting it approved for public release). It will be in th public domain (free). Ranga. David Frascone wrote: > Has anyone out there written a sip parser in yacc/bison? I'm trying to find > a free grammar for it if anyone has. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------53D8C37F6C1A1A5AB4F43976 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Not yacc but antlr (output language is java). Stay tuned... I will put one out in a matter of 2 weeks  (I am documenting it and getting it approved for public release).   It will be in th public domain (free).

Ranga.
 

David Frascone wrote:

Has anyone out there written a sip parser in yacc/bison?  I'm trying to find
a free grammar for it if anyone has.

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

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------53D8C37F6C1A1A5AB4F43976-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 17:16:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20578 for ; Wed, 15 Nov 2000 17:16:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7687F44379; Wed, 15 Nov 2000 16:16:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 2C8AF44336 for ; Wed, 15 Nov 2000 16:15:01 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id RAA19638; Wed, 15 Nov 2000 17:09:26 -0500 (EST) Message-ID: <3A130AB9.9A527F9E@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------94702359900EB01B8FA23565" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 17:14:17 -0500 --------------94702359900EB01B8FA23565 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Chris Harris wrote: > All, > > Now that the JAIN SIP API is using interfaces instead of classes for Bravo! Is it out for public review as yet? > > messages and headers, the implementations of these interfaces will have > their own parsing mechanisms. Currently the API set methods throw > IllegalArgumentExceptions if the user attempts to use a null or > zero-length parameter. The question now is should an implementation > throw an IllegalArgument if it doesn't like the value, or should we > create an exception for anything implementation-specific. I suggest we create an exception class for all parser specific exceptions and have parsers subclass it to their taste (some may want to have finer grained exceptions than others). How about a generic SIPParseException class which is basically a "tagging" class from which implementations can subclass specific exceptions. In general, for standard headers, exceptions on illegally formatted headers (see recommendation below) can be delayed or thrown anytime (there is no request-reply model in SIP so the client UAS will not be necessarily waiting for a reply although it could retry endlessly....) > > > An example of this is the AcceptLanguageHeader. The API allows any > String that is not null or zero-length be used as the language range. > Obviously an implementation should be stricter on the content of this > String. Yes but the parser need not be strict. > > > The reason we are so tolerant of parameter values was that the headers > were originally defined as classes in the API, and we did not want to > include a full SIP parser in the API. However, now that interfaces are > used, an alternative would be to simply extend the definition of an > illegal argument - for example, the implementation should throw an > IllegalArgumentException if the language range does not conform to the > RFC. (Of course testing this would be another matter entirely!) > > Another separate issue is - what should an implementation do if receives > > something from the network that it cannot parse correctly? Should the > JAIN SIP application be made aware of it, or should the implementation > automatically send back the appropriate response to the network? This > obviously depends on whether the implementation is lazy-parsing or > parsing the entire message up front, and we have to accomodate both > scenarios (this is after all one of the main reasons we moved from > classes to interfaces) By application I assume you are referring to the event handler portion of the stack. Heres my take.... I think specific kinds of errors (for example unrecognized method keywords that identifies the header type) should generate prompt notification as a way of allowing implementers to build extensions but that does not need to apply to the entire message. Thus, what I am suggesting is that even a lazy parser look at the first portion of the header and invoke a handler if the header is not one of the pre-defined types supported by the parser. However, this does not need to apply to all headers - for example if the header is a standard header (e.g. Contact header) but the rest of the header is bad. Prompt SIP responses from the server under such circumstances are not a requirement of the spec (as far as I know). Hence, the way I understand it (correct me if I am wrong) it would be legal for the server to do a number of things under this scenario including just ignore the mangled header (and drop it silently) so this behavior is best left unspecified in JAIN-SIP (gives implementations the ability to choose to do whatever they want). Thanks. Regards, Ranga. > > > Your opinions are of course welcomed. > > Regards, > Chris Harris > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------94702359900EB01B8FA23565 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Chris Harris wrote:
All,

Now that the JAIN SIP API is using interfaces instead of classes for


Bravo!  Is it out for public review as yet?
 

 
messages and headers, the implementations of these interfaces will have
their own parsing mechanisms. Currently the API set methods throw
IllegalArgumentExceptions if the user attempts to use a null or
zero-length parameter. The question now is should an implementation
throw an IllegalArgument if it doesn't like the value, or should we
create an exception for anything implementation-specific.

I suggest we create an exception class for all parser specific exceptions and have parsers subclass it to their taste (some may want to have finer grained exceptions than others). How about a generic SIPParseException class which is basically a "tagging" class from which implementations can subclass specific exceptions. In general, for standard headers,  exceptions on illegally formatted headers (see recommendation below) can be delayed or thrown anytime (there is no request-reply model in SIP so the client UAS will not be necessarily waiting for a reply although it could retry endlessly....)
 
 

 

An example of this is the AcceptLanguageHeader. The API allows any
String that is not null or zero-length be used as the language range.
Obviously an implementation should be stricter on the content of this
String.


Yes but the parser need not be strict.

 

The reason we are so tolerant of parameter values was that the headers
were originally defined as classes in the API, and we did not want to
include a full SIP parser in the API. However, now that interfaces are
used, an alternative would be to simply extend the definition of an
illegal argument - for example, the implementation should throw an
IllegalArgumentException if the language range does not conform to the
RFC. (Of course testing this would be another matter entirely!)

Another separate issue is - what should an implementation do if receives

something from the network that it cannot parse correctly? Should the
JAIN SIP application be made aware of it, or should the implementation
automatically send back the appropriate response to the network? This
obviously depends on whether the implementation is lazy-parsing or
parsing the entire message up front, and we have to accomodate both
scenarios (this is after all one of the main reasons we moved from
classes to interfaces)

By application I assume you are referring to the event handler portion of the stack. Heres my take....

I think specific kinds of errors (for example unrecognized  method keywords that identifies the header type)  should generate prompt notification as a way of allowing implementers to build  extensions but that does not need to apply to the entire message. Thus, what I am suggesting is that even a lazy parser look at the first portion of the header and invoke a handler if the header is not one of the pre-defined types supported by the parser.

However, this does not need to apply to all headers - for example if the header is a standard header  (e.g. Contact header) but the rest of the header is bad. Prompt SIP responses from the server under such circumstances are not a requirement of the spec (as far as I know).  Hence, the way I understand it (correct me if I am wrong)  it would be legal for the server to do a number of things under this scenario including just ignore the mangled header  (and drop it silently)  so this behavior is  best left unspecified in JAIN-SIP (gives implementations the ability to choose to do whatever they want).

Thanks.
 

Regards,

Ranga.

 

Your opinions are of course welcomed.

Regards,
Chris Harris

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

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------94702359900EB01B8FA23565-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 17:17: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 RAA21227 for ; Wed, 15 Nov 2000 17:17:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C5C544392; Wed, 15 Nov 2000 16:17:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 05ED244336 for ; Wed, 15 Nov 2000 16:16:49 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 15 Nov 2000 16:16:19 -0600 (CST) From: Billy Biggs To: Jo Hornsby Cc: Sean Olson , Jonathan Rosenberg , Neil Deason , Bertil Engelholm , SIP List Subject: Record-Route (was Re: [SIP] Identification problem) Message-ID: <20001115161619.A29144@div8.net> References: <3A07C09B.DAC8B5E5@ericsson.com> <001b01c04976$80fa26a0$4e34c3c1@ubiquity.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <001b01c04976$80fa26a0$4e34c3c1@ubiquity.co.uk>; from jhornsby@ubiquity.net on Wed, Nov 08, 2000 at 11:24:48AM -0000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 16:16:19 -0600 I think Jo was on the right track with his suggestion of adding a "uri" parameter, but I do not agree that it is worthwhile to add special processing requirements to support a shaky failover solution. I believe that each proxy can decide for itself how much state information to put in a Record-Route URI, and to provide a URI which will route back to an appropriate destination for requests in each direction: Method 1, transactions must go through this proxy to get through a firewall, no state required: --> R-R: Method 2, state kept with no failover: --> R-R: Method 3, state kept in shared database with friend proxies: --> R-R: Method 4, need original request URI for internal state: --> R-R: Method 6, oldschool proxy, doesn't mess up algorithm, provides a failover only in one direction: --> R-R: In each of these cases, the proxy chooses an appropriate URI based on its needs for state or failure case. Jonathan brought up the "fundamental invariant": > That aside, the motivation for doing this oddball combination was to > try and preserve a "fundamental invariant" of SIP, which was that the > request URI should always refer to an entity that the request is > actually addressed to. [...] Personally, I think the request URI should reflect the next hop in the Route and not the final destination, otherwise we will get problems with transparent outbound proxies and clients that don't put the maddr in the request URI. Ugh. Also remember that in many Record-Route situations, the final destination is not reachable except through the proxy. I don't think it is worthwhile to overcomplicate the protocol just to provide a _possible_ (and maybe unlikely) failover solution. I like the algorithm for clients and proxies to be dead simple: 1. Proxies prepend an address to the front of the R-R list. 2. If a client receives a R-R in a request, it copies it to the Route directly and then appends the Contact. 3. If a client receives a R-R in a final response, it reverse copies it to the Route and then appends the Contact. 4. When a client sends a request, it pops the first route and then uses it as the Request-URI. This algorithm is currently followed by multiple existing implementations. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 17:42: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 RAA00713 for ; Wed, 15 Nov 2000 17:42:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 68E1C4438A; Wed, 15 Nov 2000 16:42:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lists.bell-labs.com (Postfix) with ESMTP id 2E8B044336 for ; Wed, 15 Nov 2000 16:41:16 -0500 (EST) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id AB864335; Wed, 15 Nov 2000 16:41:09 -0600 (CST) Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 9B199301; Wed, 15 Nov 2000 16:41:09 -0600 (CST) Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Wed, 15 Nov 2000 16:41:09 -0600 Message-ID: <202F03744BDCD31194270000F803CA9E77011A@cxoexc2.cxo.dec.com> From: "Maddux, Michel" To: "'Vladislav Zubarev'" , Igor Slepchin Cc: sip@lists.bell-labs.com, "Lawhorn, Tom" , "Byrne, Sam" , "Hurlbert, John" Subject: RE: [SIP] SIP - H.323 - INVITE - No media line. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 16:41:03 -0600 RFC 2543 Section B.4 states: B.4 Delayed Media Streams In some cases, a caller may not know the set of media formats which it can support at the time it would like to issue an invitation. This is the case when the caller is actually a gateway to another protocol which performs media format negotiation after call setup. When this occurs, a caller MAY issue an INVITE with a session description that contains no media lines. The callee SHOULD interpret this to mean that the caller wishes to participate in a multimedia session described by the session description, but that the media streams are not yet known. The callee SHOULD return a session description indicating the streams and media formats it is willing to support, however. The caller MAY update the session description either in the ACK request or in a re-INVITE at a later time, once the streams are known. The I-D - Singh/Schulzrinne states: "... [snip - to page 14...] The default session description MUST be either empty or conatin media descriptio (m=) lines indicating lthe minimal capabilities of any H.323 terminal handled by the IWF." The sip UAC that I'm using for testing either doesn't respond correctly (e.g. with the appropriate media), or the I-D is in conflict with the spec on this item, or perhaps I'm sending an inappropriate value for the "empty" string in the SDP m= line. From my reading, I interpret the phrase "empty" to mean the following line: c=IN IP4 0.0.0.0 m=audio 0 RTP/AVP 0 Yet when I send this line, instead of getting back the expected line: c=IN IP4 real.ip.address.here m=audio 8000 RTP/AVP 8 I receive: m=audio 0 RTP/AVP 0 A blank media line is either: m= or no m= line at all. In both case the UAC issues a rejection. so I'm still unable to ascertain how to setup the port. Any comments? thanks. /m. -----Original Message----- From: Vladislav Zubarev [mailto:vladis@vovida.com] Sent: Tuesday, November 14, 2000 6:25 PM To: Igor Slepchin Cc: Maddux, Michel; sip@lists.bell-labs.com; Lawhorn, Tom; Byrne, Sam; Hurlbert, John Subject: Re: [SIP] SIP - H.323 - INVITE - No media line. Again, call scenarios with different issues resolving (like this) can be found in the following document: http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt Thanx. Igor Slepchin wrote: > 1) When 323 calls, wait until it opens first media channel. > Then issue the > INVITE, noting only a media line of that media type but with > a phony port. > When Sip replies (200 OK presumed), complete the 323 media > channel being > negotiated, giving it the Sip's media port. Then negotiate the reverse > channel with 323, saving its port, which is then transmitted > to Sip via an > ACK with a message body correcting the 323 media port. This is illegal in SIP (see section 4.2.1 in 2543bis). You should use re-INVITE if you want to modify the session offered in INVITE request. Thank you, Igor Slepchin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.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 Nov 15 17:49: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 RAA03142 for ; Wed, 15 Nov 2000 17:49:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D3234438D; Wed, 15 Nov 2000 16:49:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id 8288044336 for ; Wed, 15 Nov 2000 16:48:16 -0500 (EST) Received: from ipunity.com (w040.z208176180.sjc-ca.dsl.cnc.net [208.176.180.40]) by westhost16.westhost.net (8.8.5/8.8.5) with ESMTP id QAA28149; Wed, 15 Nov 2000 16:51:56 -0600 Message-ID: <3A13130C.AE8999A7@ipunity.com> From: jimmy Zhang X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: David Frascone , sip@lists.bell-labs.com Subject: Re: [SIP] Sip Grammars out there? References: <20001115142250.B7933@newman.frascone.com> <3A1302BE.D3E44779@nist.gov> Content-Type: multipart/alternative; boundary="------------7F71A190AC48DB5B8B84B136" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 14:49:48 -0800 --------------7F71A190AC48DB5B8B84B136 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just curioius DFA version of the parser is faster than the NFA version of the parser, which one could be faster? by how much? "M. Ranganathan" wrote: > Not yacc but antlr (output language is java). Stay tuned... I will put > one out in a matter of 2 weeks (I am documenting it and getting it > approved for public release). It will be in th public domain (free). > > Ranga. > > > David Frascone wrote: > >> Has anyone out there written a sip parser in yacc/bison? I'm trying >> to find >> a free grammar for it if anyone has. >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > -- Jimmy zhang (jz@ipunity.com) Software Engineer --------------7F71A190AC48DB5B8B84B136 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Just curioius DFA version of the parser is faster than the NFA version of the parser, which one could be faster? by how much?

"M. Ranganathan" wrote:

Not yacc but antlr (output language is java). Stay tuned... I will put one out in a matter of 2 weeks  (I am documenting it and getting it approved for public release).   It will be in th public domain (free).

Ranga.
 

David Frascone wrote:

Has anyone out there written a sip parser in yacc/bison?  I'm trying to find
a free grammar for it if anyone has.

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

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


Jimmy zhang (jz@ipunity.com)

Software Engineer
  --------------7F71A190AC48DB5B8B84B136-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 18:45:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21219 for ; Wed, 15 Nov 2000 18:45:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3147844337; Wed, 15 Nov 2000 17:45:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id F1D8044336 for ; Wed, 15 Nov 2000 17:44:21 -0500 (EST) Received: from dynamicsoft.com ([212.120.159.155]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA00200; Wed, 15 Nov 2000 18:46:31 -0500 (EST) Message-ID: <3A131F80.9060704@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> Content-Type: text/plain; charset=us-ascii; format=flowed 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, 15 Nov 2000 23:42:56 +0000 Content-Transfer-Encoding: 7bit Ranga, Thanks for the input! Comments below... Regards, Chris M. Ranganathan wrote: > > Chris Harris wrote: > >> All, >> >> Now that the JAIN SIP API is using interfaces instead of classes for >> > > Bravo! Is it out for public review as yet? > It's not yet. I can email the current version to anyone who is interested. The first public draft will be available from Sun's site, for the next bake-off > > > >> >> messages and headers, the implementations of these interfaces will have >> their own parsing mechanisms. Currently the API set methods throw >> IllegalArgumentExceptions if the user attempts to use a null or >> zero-length parameter. The question now is should an implementation >> throw an IllegalArgument if it doesn't like the value, or should we >> create an exception for anything implementation-specific. > > I suggest we create an exception class for all parser specific > exceptions and have parsers subclass it to their taste (some may want > to have finer grained exceptions than others). How about a generic > SIPParseException class which is basically a "tagging" class from > which implementations can subclass specific exceptions. In general, > for standard headers, exceptions on illegally formatted headers (see > recommendation below) can be delayed or thrown anytime (there is no > request-reply model in SIP so the client UAS will not be necessarily > waiting for a reply although it could retry endlessly....) > The implementations can certainly subclass such an exception - but the application will only know about the base exception from the API - so I think a SipParseException is sufficient. I assume you mean we keep the IllegalArgumentException for just the null argument case, and use the SipParseException for all other unparsable String arguments (including zero-length)? We need to decide whether this should be a checked or runtime exception. > > > > >> >> >> An example of this is the AcceptLanguageHeader. The API allows any >> String that is not null or zero-length be used as the language range. >> Obviously an implementation should be stricter on the content of this >> String. >> > > Yes but the parser need not be strict. > OK - but chances are it will be stricter than the API :) >> >> >> The reason we are so tolerant of parameter values was that the headers >> were originally defined as classes in the API, and we did not want to >> include a full SIP parser in the API. However, now that interfaces are >> used, an alternative would be to simply extend the definition of an >> illegal argument - for example, the implementation should throw an >> IllegalArgumentException if the language range does not conform to the >> RFC. (Of course testing this would be another matter entirely!) >> >> Another separate issue is - what should an implementation do if receives >> >> something from the network that it cannot parse correctly? Should the >> JAIN SIP application be made aware of it, or should the implementation >> automatically send back the appropriate response to the network? This >> obviously depends on whether the implementation is lazy-parsing or >> parsing the entire message up front, and we have to accomodate both >> scenarios (this is after all one of the main reasons we moved from >> classes to interfaces) >> > By application I assume you are referring to the event handler portion > of the stack. Heres my take.... > > I think specific kinds of errors (for example unrecognized method > keywords that identifies the header type) should generate prompt > notification as a way of allowing implementers to build extensions > but that does not need to apply to the entire message. Thus, what I am > suggesting is that even a lazy parser look at the first portion of the > header and invoke a handler if the header is not one of the > pre-defined types supported by the parser. > Well the implementation should pass an unrecognised header to the JAIN SIP application (as a generic Header)- after all the JAIN SIP application might be aware of extensions that the underlying implementation knows nothing about. > However, this does not need to apply to all headers - for example if > the header is a standard header (e.g. Contact header) but the rest of > the header is bad. > If lazy parsing is being used, this bad part will not be discovered until the application attempts to access it - so should the get methods throw the JainSipParseException too? (Again this may affect whether the exception should be checked or not) > Prompt SIP responses from the server under such circumstances are not > a requirement of the spec (as far as I know). Hence, the way > I understand it (correct me if I am wrong) it would be legal for the > server to do a number of things under this scenario including just > ignore the mangled header (and drop it silently) so this behavior > is best left unspecified in JAIN-SIP (gives implementations the > ability to choose to do whatever they want). > Is dropping the broken header the usual way to handle this case? Do any SIP implementations keep the header and leave the header content as a string? > Thanks. > > > Regards, > > Ranga. > >> >> >> Your opinions are of course welcomed. >> >> Regards, >> Chris Harris >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 19:29:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05697 for ; Wed, 15 Nov 2000 19:29:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5689B4434A; Wed, 15 Nov 2000 18:29:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pigeon.vovida.com (a98.vovida.com [209.237.8.98]) by lists.bell-labs.com (Postfix) with ESMTP id F0B8344336 for ; Wed, 15 Nov 2000 18:28:32 -0500 (EST) Received: from vovida.com ([209.237.8.113]) by pigeon.vovida.com (Netscape Messaging Server 4.15) with ESMTP id G43CT000.BXB; Wed, 15 Nov 2000 16:17:24 -0800 Message-ID: <3A132A1F.1470D2A3@vovida.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: "Maddux Michel" Cc: Igor Slepchin , sip@lists.bell-labs.com, "Lawhorn Tom" , "Byrne Sam" , "Hurlbert John" Subject: Re: [SIP] SIP - H.323 - INVITE - No media line. References: <202F03744BDCD31194270000F803CA9E77011A@cxoexc2.cxo.dec.com> Content-Type: multipart/alternative; boundary="------------B85EED76782735FE71D84619" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 16:28:15 -0800 --------------B85EED76782735FE71D84619 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Empty" means SIP message does NOT contain SDP AT ALL, which I guess means the same as it says in RFC2543 (no media lines). The problem is the most SUAs do not support this "empty" INVITE right now. The UA, which supports this feature for sure is CISCO IP PHONE 7960, with the latest load. There could be some other implementations out there as well. Thanx. "Maddux, Michel" wrote: > RFC 2543 Section B.4 states: > > > B.4 Delayed Media Streams > > In some cases, a caller may not know the set of media formats which > it can support at the time it would like to issue an invitation. This > is the case when the caller is actually a gateway to another protocol > which performs media format negotiation after call setup. When this > occurs, a caller MAY issue an INVITE with a session description that > contains no media lines. The callee SHOULD interpret this to mean > that the caller wishes to participate in a multimedia session > described by the session description, but that the media streams are > not yet known. The callee SHOULD return a session description > indicating the streams and media formats it is willing to support, > however. The caller MAY update the session description either in the > ACK request or in a re-INVITE at a later time, once the streams are > known. > > The I-D - Singh/Schulzrinne states: "... [snip - to page 14...] The default > session description MUST be either empty or conatin media descriptio (m=) > lines indicating lthe minimal capabilities of any H.323 terminal handled by > the IWF." > > > The sip UAC that I'm using for testing either doesn't respond correctly > (e.g. with the appropriate media), > or the I-D is in conflict with the spec on this item, or perhaps I'm sending > an inappropriate value for the "empty" > string in the SDP m= line. From my reading, I interpret the phrase "empty" > to mean the following line: > > c=IN IP4 0.0.0.0 > m=audio 0 RTP/AVP 0 > > Yet when I send this line, instead of getting back the expected line: > > c=IN IP4 real.ip.address.here > m=audio 8000 RTP/AVP 8 > > I receive: m=audio 0 RTP/AVP 0 > > A blank media line is either: > > m= > or no m= line at all. In both case the UAC issues a rejection. > > so I'm still unable to ascertain how to setup the port. Any comments? > thanks. /m. > > -----Original Message----- > From: Vladislav Zubarev [mailto:vladis@vovida.com] > Sent: Tuesday, November 14, 2000 6:25 PM > To: Igor Slepchin > Cc: Maddux, Michel; sip@lists.bell-labs.com; Lawhorn, Tom; Byrne, Sam; > Hurlbert, John > Subject: Re: [SIP] SIP - H.323 - INVITE - No media line. > > Again, call scenarios with different issues resolving (like this) can > be found in the following document: > > http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt > > > Thanx. > > Igor Slepchin wrote: > > > 1) When 323 calls, wait until it opens first media channel. > > Then issue the > > INVITE, noting only a media line of that media type but with > > a phony port. > > When Sip replies (200 OK presumed), complete the 323 media > > channel being > > negotiated, giving it the Sip's media port. Then negotiate the reverse > > channel with 323, saving its port, which is then transmitted > > to Sip via an > > ACK with a message body correcting the 323 media port. > > This is illegal in SIP (see section 4.2.1 in 2543bis). You should use > re-INVITE if you want to modify the session offered in INVITE request. > > Thank you, > Igor Slepchin > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > -- > > Vladislav Zubarev mailto:vladis@vovida.com > > > Software Engineer > > Vovida Networks, Inc. http://www.vovida.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Vladislav Zubarev mailto:vladis@vovida.com Software Engineer Vovida Networks, Inc. http://www.vovida.com --------------B85EED76782735FE71D84619 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit "Empty" means SIP message does NOT contain SDP AT ALL, which I guess
means the same as it says in RFC2543 (no media lines).

The problem is the most SUAs do not support this "empty" INVITE right now.

The UA, which supports this feature for sure is CISCO IP PHONE 7960,
with the latest load. There could be some other implementations out there
as well.

Thanx.

"Maddux, Michel" wrote:

RFC 2543 Section B.4 states:

<!--StartFragment-->
B.4 Delayed Media Streams

   In some cases, a caller may not know the set of media formats which
   it can support at the time it would like to issue an invitation. This
   is the case when the caller is actually a gateway to another protocol
   which performs media format negotiation after call setup. When this
   occurs, a caller MAY issue an INVITE with a session description that
   contains no media lines. The callee SHOULD interpret this to mean
   that the caller wishes to participate in a multimedia session
   described by the session description, but that the media streams are
   not yet known. The callee SHOULD return a session description
   indicating the streams and media formats it is willing to support,
   however. The caller MAY update the session description either in the
   ACK request or in a re-INVITE at a later time, once the streams are
   known.

The I-D - Singh/Schulzrinne states: "... [snip - to page 14...] The default
session description MUST be either empty or conatin media descriptio (m=)
lines indicating lthe minimal capabilities of any H.323 terminal handled by
the IWF."
 

The sip UAC that I'm using for testing either doesn't respond correctly
(e.g. with the appropriate media),
or the I-D is in conflict with the spec on this item, or perhaps I'm sending
an inappropriate value for the "empty"
string in the SDP m= line.  From my reading, I interpret the phrase "empty"
to mean the following line:

c=IN IP4 0.0.0.0
m=audio 0 RTP/AVP 0

Yet when I send this line, instead of getting back the expected line:

c=IN IP4 real.ip.address.here
m=audio 8000 RTP/AVP 8

I receive: m=audio 0 RTP/AVP 0

A blank media line is either:

m=
or no m= line at all.  In both case the UAC issues a rejection.

so I'm still unable to ascertain how to setup the port.  Any comments?
thanks. /m.

-----Original Message-----
From: Vladislav Zubarev [mailto:vladis@vovida.com]
Sent: Tuesday, November 14, 2000 6:25 PM
To: Igor Slepchin
Cc: Maddux, Michel; sip@lists.bell-labs.com; Lawhorn, Tom; Byrne, Sam;
Hurlbert, John
Subject: Re: [SIP] SIP - H.323 - INVITE - No media line.

Again, call scenarios with different issues resolving (like this) can
be found in the following document:

http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt
<http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt>

Thanx.

Igor Slepchin wrote:

> 1) When 323 calls, wait until it opens first media channel.
> Then issue the
> INVITE, noting only a media line of that media type but with
> a phony port.
> When Sip replies (200 OK presumed), complete the 323 media
> channel being
> negotiated, giving it the Sip's media port. Then negotiate the reverse
> channel with 323, saving its port, which is then transmitted
> to Sip via an
> ACK with a message body correcting the 323 media port.

This is illegal in SIP (see section 4.2.1 in 2543bis). You should use
re-INVITE if you want to modify the session offered in INVITE request.

Thank you,
Igor Slepchin

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

--

Vladislav Zubarev         mailto:vladis@vovida.com
<mailto:vladis@vovida.com>

Software Engineer

Vovida Networks, Inc.     http://www.vovida.com <http://www.vovida.com>
 

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

-- 
Vladislav Zubarev        mailto:vladis@vovida.com
Software Engineer   
Vovida Networks, Inc.    http://www.vovida.com
  --------------B85EED76782735FE71D84619-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 15 20:55:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25282 for ; Wed, 15 Nov 2000 20:55:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E647644358; Wed, 15 Nov 2000 19:55:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 55B7144336 for ; Wed, 15 Nov 2000 19:54:17 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 17:53:54 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Culpepper, Bert'" , "'sip@lists.bell-labs.com'" Cc: Alan Johnston Subject: RE: [SIP] SIP ringback tone MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 17:53:45 -0800 Right, so if a PSTN gateway knows that the callee is being alerted then it should send a 180 with (or without) SDP. Otherwise, if the PSTN gateway only knows that inband call progress tones are being provided by the PSTN network (but not the callee alerting state) then I agree 183 is more appropriate. If the network later confirms that the callee is being alerted, the gateway can always send a subsequent 180 Ringing without SDP (or perhaps with a duplicate SDP body for robustness). Cheers, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > Sent: Thursday, November 16, 2000 2:06 AM > To: 'sip@lists.bell-labs.com' > Cc: Alan Johnston; Fairlie-Cuninghame, Robert > Subject: RE: [SIP] SIP ringback tone > > > I think that Alan and Robert are "saying" the same thing. My > understanding is that a UAC, upon receipt of a 180 without > SDP, indicates to the user that the callee is being alerted. > It can use whatever method it desires such as a pop-up > message, playing an audible ringback tone, etc. to indicate > this to the local user. If the 180 included a SDP, the UAC can > present the media stream or not. However, I believe the UAC > should cease its local indication (if any) upon receipt of a 183. > The UAS sends a 183 (with SDP) to indicate that it will be > sending early media (typically some call progress message). > The local ringing indication should cease at the UAC so that > the user can "hear" the early media (disposition of the call). > > If the UAS wishes to provide ringback tone it can send a 180 > with SDP. A 183 with SDP could be used too but why not use > the Ringing response for ringback instead of a Session > Progress response for ringback. As Robert writes, a 180 > indicates a specific state. The 180 with local alerting indication > at the UAC minimizes network, UAC, and UAS resources > during the setup phase and allows the UAC to locally indicate > remote alerting however it likes. If tone characteristics are > present in a header of the 180 the UAC can "customize" its > local alerting as Adam's Ringback I-D supports. > > Regards, > Bert > > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@wcom.com] > Sent: Wednesday, November 15, 2000 11:26 AM > To: Fairlie-Cuninghame, Robert > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] SIP ringback tone > > > Robert, > > In actual implementations, often a 183 will actually be sent during > ringing, due > to the fact that often a gateway will be unable to determine > definitively if > ringing or some other information is being sent in-band. My concern > is that > this reading will cause gateway vendors to assume that ringing is > taking place, > send a 180 with SDP. Then, the User Agent may also assume that > ringing is > taking place, not play the early media stream to the user. (The bis > spec > currently only says SHOULD.) If the call then receives treatment, the > user will > then have not idea why the call failed. > > I agree that a User Agent should not have to know that it is talking > to a > gateway to the PSTN. What it does need to know is that media > described in the > SDP of a 183 response MUST be played to the user, or the final outcome > of a call > may not be known. (Since 183 is a new response code, there aren't any > backwards > compatibility issues here, are there?) > > Thanks, > Alan. > > "Fairlie-Cuninghame, Robert" wrote: > > > The way the spec is written at the moment (see Section 7.1 - it > changed > > recently), a UAC should be able to accept any 1xx response (other > than 100) > > with SDP as indicating early media. eg 183, 182, 181 or 180. > Obviously they > > must have different meanings or there is no reason to have the > different > > response codes (COMET aside). Both the expired 183 draft > (explicitly) and > > the bis-02 draft (inferred) say that 183 indicates call progress > events > > _other_ than user alerting (eg "queued message", "please wait, > verifying" or > > "enter pin number" voice messages) --- yet the mechanism is the same > for 180 > > and 183. [I just think it should be made clearer in the 183 > description.] > > > > I don't understand your point about requiring support for two > mechanisms and > > that it "masks whether I'm going to the PSTN or another SIP endpoint > > identified by a telephone number". How so? And more importantly, why > is this > > necessary ? > > > > In fact I would say the opposite is true. A SIP client that is not > PSTN > > centric and doesn't bother with early media playback should not have > to know > > that 183 is actually ringback on a PSTN SIP client. The client > should simply > > know that a received 180 indicates user alerting, 182 is queued and > 183 is > > some other call progress event. > > > > Regards, > > > > Robert. > > > > -- My opinions are my own. I tried selling them once but everybody > > seems to already have one. -- > > > -----Original Message----- > > > From: David Shrader [mailto:dshrader@master-consultant.com] > > > Sent: Monday, November 13, 2000 9:54 PM > > > To: Fairlie-Cuninghame, Robert > > > Cc: SIP List > > > Subject: Re: [SIP] SIP ringback tone > > > > > > > > > Robert, > > > > > > I don't agree that 183 with SDP should only be a call > > > progress message. It > > > is a perfectly reasonable usage to support ringback. This is > > > especially > > > necessary when interworking with the PSTN where ringback is > delivered > > > inband. If you implement a system that works with the PSTN, I > think we > > > shouldn't require it to support two modes of operation. It > > > seems reasonable > > > that the use of 183 masks whether I'm going to the PSTN or another > SIP > > > endpoint identified by a telephone number and allows the > > > person or network > > > being called to provide whatever inband indication it chooses. > > > > > > David > > > > > > ---------------------------- > > > David Shrader > > > Master Consultant, Inc. > > > dshrader@master-consultant.com > > > http://www.EyeForTheFuture.com > > > > > > > From: "Fairlie-Cuninghame, Robert" > > > > Date: Mon, 13 Nov 2000 03:33:35 -0800 > > > > To: "'Henry Sinnreich'" > > > > Cc: "'sip@lists.bell-labs.com'" > > > > Subject: RE: [SIP] SIP ringback tone > > > > > > > > Henry, > > > > > > > > Innovative ringback greetings definitely seem like a case > > > for an early media > > > > to me. > > > > > > > > As an aside, many people still seem to erroroneously think > > > that 183 Session > > > > Progress should be used for early-media ring-back. 180 > > > Ringing with SDP > > > > should be used for ringback purposes, 183 with SDP should > > > only be used for > > > > call progress messages (ie, not alerting the user). I still > > > think this needs > > > > to be made clearer in the spec! > > > > > > > > Cheers, > > > > > > > > Robert. > > > > > > > > -- My opinions are my own. I tried selling them once but > everybody > > > > seems to already have one. -- > > > > > > > >> -----Original Message----- > > > >> From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > > > >> Sent: Monday, November 13, 2000 6:18 AM > > > >> To: adam.roach@ericsson.com; IETF SIP (E-mail) > > > >> Subject: [SIP] SIP ringback tone > > > >> > > > >> > > > >> The draft on "Ringback tones in SIP-Based Telephony" shows > > > >> impressive work > > > >> on preserving legacy country specific ring back tones. I > > > >> wonder if we would > > > >> not be better of by adding a > > > >> > > > >> SIP Ringback Tone > > > >> ================= > > > >> > > > >> With some optional fields where service providers could > > > add innovative > > > >> greetings. > > > >> > > > >> Henry > > > >> > > > >> Henry Sinnreich > > > >> WorldCom > > > >> 400 International Parkway, > > > >> Richardson, Texas, 75081 > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> SIP mailing list > > > >> SIP@lists.bell-labs.com > > > >> http://lists.bell-labs.com/mailman/listinfo/sip > > > >> > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 15 21:01: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 VAA26614 for ; Wed, 15 Nov 2000 21:01:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B18F44397; Wed, 15 Nov 2000 20:01:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AEAA844394 for ; Wed, 15 Nov 2000 20:00:03 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA00724 for ; Wed, 15 Nov 2000 21:02:20 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y7YR>; Wed, 15 Nov 2000 20:58:22 -0500 Message-ID: From: Igor Slepchin To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" Subject: [SIP] draft-byerly-sip-radius-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 15 Nov 2000 20:58:21 -0500 Minor comment on draft-byerly-sip-radius-00.txt: the draft seems to deviate unnecessarily from the challenge and credentials syntax specified in RFC2617, i.e., it uses semicolon to separate challenge/credentials parameters instead of reusing comma-separation mandated by HTTP Basic/Digest. I think consistency with HTTP should be maintained wherever possible. Thank you, 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 Nov 15 23:51:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10645 for ; Wed, 15 Nov 2000 23:51:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D789244394; Wed, 15 Nov 2000 22:51:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web10304.mail.yahoo.com (web10304.mail.yahoo.com [216.136.130.82]) by lists.bell-labs.com (Postfix) with SMTP id 2AEAD44336 for ; Wed, 15 Nov 2000 22:50:06 -0500 (EST) Message-ID: <20001116044959.50241.qmail@web10304.mail.yahoo.com> Received: from [203.197.179.22] by web10304.mail.yahoo.com; Wed, 15 Nov 2000 20:49:59 PST From: james jack To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Discussion On 485 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 15 Nov 2000 20:49:59 -0800 (PST) Dear All: I have one question to discuss, on RFC2543bis02 page 68, which says"The callee address provided in the request was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact headers. Revealing alternatives can infringe on privacy concerns of the user or the organization. It MUST be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices if the request address was ambiguous." I can't understand how the UAS or server can judge this address is ambiguous,if there is no such callee after comparison, 404 response code can be sent out. How can the server know under what situation 485 will be sent out. Could anyone give me some suggestion? Thanks in advance! Best regards! Yours: Ford If the server receives a request whose To address or request-uri is ambiguous then the server may respond with a 485 response. The response usually contains a list of un-ambiguous addresses that are semantically similar to the ambiguous address. However this listing should be suppressed or displayed based on the request address. The pattern by which we can find if an address is ambiguous or not available is not clear to me. Based on this method only we can either send a 485 or 404 response. __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 16 08:23:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22415 for ; Thu, 16 Nov 2000 08:23:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E22E4436A; Thu, 16 Nov 2000 07:23:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from lornadoon.akc.com (lornadoon.donet.com [205.133.113.5]) by lists.bell-labs.com (Postfix) with ESMTP id 9A67644336 for ; Thu, 16 Nov 2000 07:21:59 -0500 (EST) Received: from cc89326b (backup.akc.com [24.6.239.68]) by lornadoon.akc.com (8.9.3/8.9.3) with SMTP id IAA00485; Thu, 16 Nov 2000 08:19:54 -0500 Message-ID: <007101c04fc7$e5829380$44ef0618@union1.nj.home.com> Reply-To: "Al Costanzo" From: "Al Costanzo" To: , "Al Costanzo" Cc: 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 Subject: [SIP] Modifying the ID for SIP: draft-costanzo-dns-gl-03.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 07:22:30 -0500 Content-Transfer-Encoding: 7bit My comments below: From: "Henry Sinnreich" To: Cc: "Tom Redman" ; "Ikhlaq_Sidhu" ; "Jay Batson" ; "Jean Joseph Brierre" ; "Ronald Bonica" Sent: Sunday, November 12, 2000 3:40 AM Subject: Definition of the DNS GL Resource Record > Costanzo, > > You may already be aware of it, your I-D on > Definition of the DNS GL Resource Record is of high interest to the IP > communications community. Especially, if you have any additional ideas how > to use this service for 911 calls from IP SIP phones. Suggest to bring it to > attention of the > IETF SIP WG list - sip@lists.bell-labs.com, > SIP Forum list - SIP Forum Discussion - discussion@sipforum.org > > Henry > > Henry Sinnreich > WorldCom > 400 International Parkway, > Dept. 1489, 2A313 > Richardson, Texas, 75081 > Cell: 972-897-7723 > Office: 972-729-4271 > Hello, I am Al Costanzo, I submitted this email to the list but never saw it posted so here it is again,,, I wrote ID , it was suggested to me (see above) to to bring it to the attention of this WG for consideration, the draft has currently not moved forward, so there is time to make modifications to it and re-submit it to the IESG. would appreciate a comment back either way if the WG is interested in using the draft, I would be more than willing to work with the working group to modify it to allow it to do what you need for 911 calls from IP SIP phones, which is an ideal usage for the GL RR. Basically this draft allows physical locations to be stored as a RR in DNS, the point being that this method of storing the loctions is much better since everyone already uses DNS. Please let me know what you think. Regards, Al Costanzo > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 16 09:06: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 JAA07927 for ; Thu, 16 Nov 2000 09:06:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D75C44355; Thu, 16 Nov 2000 08:06:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by lists.bell-labs.com (Postfix) with ESMTP id 8F87B44336 for ; Thu, 16 Nov 2000 08:05:08 -0500 (EST) Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id eAGE4rl19685 for ; Thu, 16 Nov 2000 15:04:53 +0100 (MET) Received: from alcatel.be ([138.203.34.184]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256999.004D536F; Thu, 16 Nov 2000 15:04:36 +0100 Message-ID: <3A13E964.244371EC@alcatel.be> From: Tom Batsele Organization: Alcatel X-Mailer: Mozilla 4.72 [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] Refer method Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 15:04:20 +0100 Content-Transfer-Encoding: 7bit I understand a REFER method is used to ask a User Agent to start sending an INVITE to a party specified in the refer-to header. What would be the consequence of cancelling the REFER transaction, would it cancel the INVITE transaction which is in progress ? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 16 09:51:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26372 for ; Thu, 16 Nov 2000 09:51:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D6CE944370; Thu, 16 Nov 2000 08:51:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id CFEB244336 for ; Thu, 16 Nov 2000 05:29:21 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09571; Thu, 16 Nov 2000 06:29:03 -0500 (EST) Message-Id: <200011161129.GAA09571@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-cc-transfer-02.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 06:29:03 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Call Control Author(s) : R. Sparks Filename : draft-ietf-sip-cc-transfer-02.txt Pages : 19 Date : 15-Nov-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-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-cc-transfer-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-cc-transfer-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001115141338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-cc-transfer-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-cc-transfer-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001115141338.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 Nov 16 10:38: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 KAA14662 for ; Thu, 16 Nov 2000 10:38:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4079B443A4; Thu, 16 Nov 2000 09:38:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id B655E44336 for ; Thu, 16 Nov 2000 09:37:27 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id KAA03885; Thu, 16 Nov 2000 10:29:26 -0500 (EST) Message-ID: <3A13FDA7.8AD1474@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: multipart/alternative; boundary="------------A3860FFF96F657C20940CF74" Subject: [SIP] SIP Headers versus message contents. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 10:30:47 -0500 --------------A3860FFF96F657C20940CF74 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 This is for the designers of SIP . ( It is NOT a suggestion for re-deisgn so dont pounce on me for asking this one) : I am a bit puzzled by the way SIP messages were designed. If SIP allows for different kinds of headers and new extension headers to be added (as evidenced by the plethora of extension draft proposals), does that subsume the need for message contents (and vice-versa) ? For example the sdp message contents can just be a MessageContents header (albiet a long one). Thanks Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------A3860FFF96F657C20940CF74 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  This is  for the designers of SIP .    ( It is NOT a suggestion for re-deisgn so dont pounce on me for asking this one) :

I am a bit puzzled by the way SIP messages were designed.   If SIP allows for different kinds of headers and new  extension headers to be added  (as evidenced by the plethora  of extension draft proposals),  does that subsume the need for message contents (and vice-versa) ?  For example the sdp message contents can just be a MessageContents header (albiet a long one).

Thanks

Ranga. 

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------A3860FFF96F657C20940CF74-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 16 10:44:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16922 for ; Thu, 16 Nov 2000 10:44:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2EA85443AA; Thu, 16 Nov 2000 09:44:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 46591443AA for ; Thu, 16 Nov 2000 09:43:46 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA21740; Thu, 16 Nov 2000 10:43:37 -0500 (EST) Message-ID: <3A1400A9.9C1017F4@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Headers versus message contents. References: <3A13FDA7.8AD1474@nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 10:43:37 -0500 Content-Transfer-Encoding: 7bit "M. Ranganathan" wrote: > > This is for the designers of SIP . ( It is NOT a suggestion for > re-deisgn so dont pounce on me for asking this one) : > > I am a bit puzzled by the way SIP messages were designed. If > SIP allows for different kinds of headers and new extension headers > to be added (as evidenced by the plethora of extension draft > proposals), does that subsume the need for message contents (and > vice-versa) ? For example the sdp message contents can just be a > MessageContents header (albiet a long one). The division roughly reflects a division between what describes sessions as a whole (headers) and what describes sessions in their data stream details (body). This makes it easier, for example, to upgrade to a new session description format, without changing the software in proxies. In practice, the idea is that proxies and redirect servers should keep their hands and noses out of the message body, while being free to inspect and, with restrictions, modify the headers. NATs, as usual, break this model, but then NATs are warts on the Internet architecture, so this is no surprise. -- 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 Nov 16 13:11: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 NAA12050 for ; Thu, 16 Nov 2000 13:11:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F4F34435F; Thu, 16 Nov 2000 12:11:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.barak.net.il (mail.barak.net.il [206.49.94.213]) by lists.bell-labs.com (Postfix) with ESMTP id 8903544336 for ; Thu, 16 Nov 2000 12:10:26 -0500 (EST) Received: from air1.airslide.com ([212.150.80.240]) by mail.barak.net.il (8.9.3/8.9.1) with ESMTP id UAA28374 for ; Thu, 16 Nov 2000 20:10:15 +0200 (IST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <854C0C09E30AD04FB3A0593CCB561F630F6385@air1.airslide.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Index: AcBP+ELSp5FUaGwEQvmeCOzio4p42g== From: "sip" To: Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 20:08:45 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA12050 ------------------------------------------------------------------------ ------------------------------------------------------------------------ ---------------- Lichtnayer Ilan MIS Manager, Airslide Systems Ltd. Cell: 054-416453 lilan@airslide.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 Nov 16 13:13: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 NAA12981 for ; Thu, 16 Nov 2000 13:13:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C02144381; Thu, 16 Nov 2000 12:13:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.barak.net.il (mail.barak.net.il [206.49.94.213]) by lists.bell-labs.com (Postfix) with ESMTP id 9F7CE44381 for ; Thu, 16 Nov 2000 12:12:13 -0500 (EST) Received: from air1.airslide.com ([212.150.80.240]) by mail.barak.net.il (8.9.3/8.9.1) with ESMTP id UAA29671 for ; Thu, 16 Nov 2000 20:12:05 +0200 (IST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <854C0C09E30AD04FB3A0593CCB561F630F6387@air1.airslide.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: sip Thread-Index: AcBP+IQCT/2Me1JEShChawrsyI7GGQ== From: "sip" To: Subject: [SIP] sip Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 20:10:35 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA12981 ------------------------------------------------------------------------ ------------------------------------------------------------------------ ---------------- Lichtnayer Ilan MIS Manager, Airslide Systems Ltd. Cell: 054-416453 lilan@airslide.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 Nov 16 16: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 QAA05693 for ; Thu, 16 Nov 2000 16:51:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A5B644339; Thu, 16 Nov 2000 15:51:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 4C2A544336 for ; Thu, 16 Nov 2000 15:50:52 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id PAA22955; Thu, 16 Nov 2000 15:50:33 -0600 (CST) Received: from SMTP (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with SMTP id PAA00900; Thu, 16 Nov 2000 15:50:31 -0600 (CST) Received: from eamrcnt740.exu.ericsson.se ([138.85.133.41]) by 138.85.133.38 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 16 Nov 2000 21:50:25 0000 (GMT) Received: by eamrcnt740.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 16 Nov 2000 15:50:20 -0600 Message-ID: <125911DC0503D4119E2400508B0CCD2F7DE7BE@eamrcnt718.exu.ericsson.se> From: "Cathy Gearhart (EUS)" To: "'sip@lists.bell-labs.com'" Cc: "Arnoud van Wijk (ELN)" , "'henry.sinnreich@wcom.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05016.A9CEAA50" Subject: [SIP] New I-D: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 15:46:23 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05016.A9CEAA50 Content-Type: text/plain; charset="iso-8859-1" Hello, My colleagues, Arnoud van Wijk and Henry Sinnreich, and I have written the following draft: "A Proposed Set of Requirements for SIP Support for Deaf or Speech Impaired Customers". The URL for this draft is: http://search.ietf.org/internet-drafts/draft-gearhart-sip-deaf-req-00.txt and would like to solicit comments from the SIP WG mailing list. The abstract of our draft is as follows: SIP is attracting more and more attention as a valuable tool to enable and support voice and multimedia communications over the Internet. However, a significant number of potential customers for SIP-based services are for various reasons unable to, or choose not to, use voice communication technologies. This document offers a proposed set of requirements and identifies some of the key issues that need resolution to allow full accessibility for this group to SIP-based Internet communications. This document is intended to continue the discussion begun in a previous draft (see Acknowledgements) and to lay a foundation for design and implementation discussions in future drafts. Comments from deaf, hard-of-hearing, and/or speech-impaired individuals who have personal experience with frustrating communications are particularly welcome. My colleague and co-author Arnoud van Wijk is deaf and I am a certified sign language interpreter, so between us we have attempted to represent both deaf and interpreter perspectives in our document. However, we are aware that circumstances vary around the world for deaf, hard-of-hearing, and speech-impaired customers, so we are very interested in feedback from individuals who feel we may have missed something or need to clarify something. Arnoud will make a brief presentation on this draft at the SIP WG meeting at IETF '49. Thank you! ____________________ Cathy Gearhart cathy.gearhart@ericsson.com (972) 583-5268 ------_=_NextPart_001_01C05016.A9CEAA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New I-D: <draft-gearhart-sip-deaf-req-00.txt>

Hello,
My = colleagues, Arnoud van Wijk and Henry Sinnreich, and I have written the = following draft: "A Proposed Set of Requirements for SIP Support = for Deaf or Speech Impaired Customers".  The URL for this = draft is:

http://search.ietf.org/internet-drafts/draft-gearhart-= sip-deaf-req-00.txt

and would = like to solicit comments from the SIP WG mailing list.  The = abstract of our draft is as follows:

        SIP is attracting more and more = attention as a valuable tool to
          enable and = support voice and multimedia communications over the
          = Internet.  However, a significant number of potential = customers
          for = SIP-based services are for various reasons unable to, or
          choose not = to, use voice communication technologies. This document
          offers a = proposed set of requirements and identifies some of the
          key issues = that need resolution to allow full accessibility for
          this group = to SIP-based Internet communications. This document is
          intended to = continue the discussion begun in a previous draft (see
          = Acknowledgements) and to lay a foundation for design and
          = implementation discussions in future drafts.

Comments from = deaf, hard-of-hearing, and/or speech-impaired individuals who have = personal experience with frustrating communications are particularly = welcome.  My colleague and co-author Arnoud van Wijk is deaf and I = am a certified sign language interpreter, so between us we have = attempted to represent both deaf and interpreter perspectives in our = document.  However, we are aware that circumstances vary around = the world for deaf, hard-of-hearing, and speech-impaired customers, so = we are very interested in feedback from individuals who feel we may = have missed something or need to clarify something.

Arnoud will = make a brief presentation on this draft at the SIP WG meeting at IETF = '49.
Thank = you!
____________________
Cathy = Gearhart
cathy.gearhart@ericsson.com
(972) = 583-5268

------_=_NextPart_001_01C05016.A9CEAA50-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 16 18:22: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 SAA07838 for ; Thu, 16 Nov 2000 18:22:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 954BC4433B; Thu, 16 Nov 2000 17:22:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 1D25344336 for ; Thu, 16 Nov 2000 17:21:49 -0500 (EST) 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 PAA19642 for ; Thu, 16 Nov 2000 15:21:46 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAA60113; Thu, 16 Nov 2000 15:21:41 -0800 (PST) Message-Id: <4.1.20001116151548.00cc2850@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: sip@lists.bell-labs.com From: Rohan Mahy Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_79125457==_.ALT" Subject: [SIP] ID extension of REFER Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 15:21:48 -0800 --=====================_79125457==_.ALT Content-Type: text/plain; charset="us-ascii" Hi, I just submitted an ID for an extension to the REFER method that I discussed with Robert Sparks at Pittsburgh. Until it appears in the archive it is available at: ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-189-00.txt A SIP Extension: Informational Responses to the REFER method Abstract This document defines a SIP extension to the REFER method of the SIP Call Control Framework. This extension provides for the ability to convey information about the progress of the Referred request when that request is in a provisional state for a long period of time (many seconds or minutes). Comments welcome. thanks, -rohan --=====================_79125457==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

I just submitted an ID for an extension to the REFER method that I discussed with Robert Sparks at Pittsburgh.  Until it appears in the archive it is available at:

        ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-189-00.txt


        A SIP Extension: Informational Responses to the REFER method

                Abstract
This document defines a SIP extension to the REFER method of the SIP Call Control Framework.  This extension provides for the ability to convey information about the progress of the Referred request when that request is in a provisional state for a long period of time (many seconds or minutes).

Comments welcome.

thanks,
-rohan


--=====================_79125457==_.ALT-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 16 19:49: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 TAA04839 for ; Thu, 16 Nov 2000 19:49:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1AAA144340; Thu, 16 Nov 2000 18:49:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id AC60A4433C for ; Thu, 16 Nov 2000 18:48:34 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id QAA10923 for ; Thu, 16 Nov 2000 16:48:28 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAA61265; Thu, 16 Nov 2000 16:47:59 -0800 (PST) Message-Id: <4.1.20001116164233.00a83400@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: sip@lists.bell-labs.com From: Rohan Mahy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [SIP] New ID for peer-to-peer 3pcc Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 16:46:58 -0800 Hi, I just submitted an ID on a usage of REFER and presence for 3pcc which doesn't require you to keep call state or stay in the signalling path. Until it appears in the archive it can be found here: ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-peer-3pcc-00.txt Using SIP for Peer-to-Peer Third-Party Call Control Abstract The 3rd party call control draft demonstrates a usage of SIP with some of the enhancements of RFC2543bis. This usage requires that a 3pcc controller remain in the signaling path and maintain state for the duration of the call. While this is necessary in certain situations (ex: protocol translation: H.323 to SIP, SIP to RTSP, HTTP to SIP), it is sub-optimal in pure SIP environments. This draft demonstrates a usage of the REFER method and SIP for presence to allow authorized peers to participate in call control. Note that much of the functionality described in PHONECTL can be duplicated using the proposed usage. Also note that this is not an extension of SIP, merely a usage of SIP and existing extensions. Comments are welcome. thanks, -rohan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 02: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 CAA06538 for ; Fri, 17 Nov 2000 02:37:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ED3704433E; Fri, 17 Nov 2000 01:37:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by lists.bell-labs.com (Postfix) with ESMTP id 701C044336 for ; Fri, 17 Nov 2000 01:36:44 -0500 (EST) Received: from rts.nio1.loniis (rts.loniis.ru [195.201.37.111]) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id eAH7aWH18643 for ; Fri, 17 Nov 2000 10:36:35 +0300 (MSK) Received: from Vova (vova.rts.nio1.loniis [192.168.100.180]) by rts.nio1.loniis (Postfix) with SMTP id 60851223 for ; Fri, 17 Nov 2000 10:37:04 +0300 (MSK) Message-ID: <000c01c05069$40386600$b464a8c0@rts.nio1.loniis> From: "Samorezov Vladimir" To: Subject: [SIP] Proxy Search MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C05082.64FF5700" 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 17 Nov 2000 10:37:33 +0300 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C05082.64FF5700 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, All ! I didn't find answer to this question in RFC. How do proxy server search called UA? What are "routing tables" used? = What algorithm?=20 What are expected in the future? Thanks! Samorezov Vladimir! ------=_NextPart_000_0009_01C05082.64FF5700 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi, All !
I didn't find answer to this = question in=20 RFC.
How do proxy server search = called UA?=20 What are "routing tables" used? What algorithm?
What are expected in the = future?
 
Thanks! Samorezov=20 Vladimir!
------=_NextPart_000_0009_01C05082.64FF5700-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 05:03:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06548 for ; Fri, 17 Nov 2000 05:03:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2BA4644343; Fri, 17 Nov 2000 04:03:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 465B54433D for ; Fri, 17 Nov 2000 04:02:47 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id EAA23539; Fri, 17 Nov 2000 04:02:39 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id EAA21550; Fri, 17 Nov 2000 04:02:38 -0600 (CST) Received: from ericsson.com (kipe51.ki.sw.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id EAA18425; Fri, 17 Nov 2000 04:02:37 -0600 (CST) Message-ID: <3A15023A.5CA44703@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: sip@lists.bell-labs.com Subject: Re: [SIP] ID extension of REFER References: <4.1.20001116151548.00cc2850@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 11:02:34 +0100 Content-Transfer-Encoding: 7bit Hello, I am a little confused about the purpose of this I-D. The first question that springs to mind is why you don't use "183" for this purpose? The second question is whether you intend the 189 to lead to different timing than any other provisional response? (In other words, if the 189 does NOT cause different timing, than the issue of a long period (> 37 seconds) between the INVITE and 200 OK is not really solved. I realize this should be a very rare case.) /sean Rohan Mahy wrote: > Hi, > > I just submitted an ID for an extension to the REFER method that I > discussed with Robert Sparks at Pittsburgh. Until it appears in the > archive it is available at: > > ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-189-00.txt > > > A SIP Extension: Informational Responses to the REFER method > > Abstract > > This document defines a SIP extension to the REFER method of the > SIP Call Control Framework. This extension provides for the > ability to convey information about the progress of the Referred > request when that request is in a provisional state for a long > period of time (many seconds or minutes). > > > Comments welcome. > > thanks, > -rohan > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 07:08: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 HAA24155 for ; Fri, 17 Nov 2000 07:08:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F214344356; Fri, 17 Nov 2000 06:08:11 -0500 (EST) 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 ABDC74434E for ; Fri, 17 Nov 2000 06:07:51 -0500 (EST) 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 eAHC7iZ02048; Fri, 17 Nov 2000 13:07:44 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id eAHC7f504252; Fri, 17 Nov 2000 13:07:42 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id NAA12034; Fri, 17 Nov 2000 13:07:40 +0100 (MET) Message-ID: <3A151F8A.5A07F210@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Cc: Billy Biggs , Jo Hornsby , Sean Olson , Jonathan Rosenberg Subject: Re: Record-Route (was Re: [SIP] Identification problem) References: <3A07C09B.DAC8B5E5@ericsson.com> <001b01c04976$80fa26a0$4e34c3c1@ubiquity.co.uk> <8uvdf9$9f$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 13:07:38 +0100 Content-Transfer-Encoding: 7bit It's seems like we agree on removing the text from the specification about overwriting the ROUTE-URI with the URI from CONTACT/FROM. If this is done my problem to identify the call state machine is solved. The other proposals you have concerns me a little bit. Should we really use an URI for this kind of data. It will probably work fine but it's to much of a hack in my eyes. How about other types of URIs in ROUTE ? As Jonathan pointed out some weeks ago there is no maddr parameter in a TEL URL. So something needs to be done to ROUTE to handle these kind of URLs. So some parameter needs to be added to RECORD-ROUTE and ROUTE (e.g. named 'raddr' for route address). Since this does not exists today it means that there are no existing SIP implementations that can route on a URI other than a SIP URL ? If this is true, how backwards compatible do we need to be to fix this ? So before a solution is decided this time may I suggest that it covers all known cases so we don't need to change the RECORD-ROUTE/ROUTE behaviour again in the future. /Bertil Billy Biggs wrote: > > I think Jo was on the right track with his suggestion of adding a > "uri" parameter, but I do not agree that it is worthwhile to add special > processing requirements to support a shaky failover solution. > > I believe that each proxy can decide for itself how much state > information to put in a Record-Route URI, and to provide a URI which > will route back to an appropriate destination for requests in each > direction: > > Method 1, transactions must go through this proxy to get through a > firewall, no state required: > --> R-R: > > Method 2, state kept with no failover: > --> R-R: > > Method 3, state kept in shared database with friend proxies: > --> R-R: > > Method 4, need original request URI for internal state: > --> R-R: > > Method 6, oldschool proxy, doesn't mess up algorithm, provides a > failover only in one direction: > --> R-R: > > In each of these cases, the proxy chooses an appropriate URI based on > its needs for state or failure case. > > Jonathan brought up the "fundamental invariant": > > > That aside, the motivation for doing this oddball combination was to > > try and preserve a "fundamental invariant" of SIP, which was that the > > request URI should always refer to an entity that the request is > > actually addressed to. [...] > > Personally, I think the request URI should reflect the next hop in the > Route and not the final destination, otherwise we will get problems with > transparent outbound proxies and clients that don't put the maddr in the > request URI. Ugh. > > Also remember that in many Record-Route situations, the final > destination is not reachable except through the proxy. > > I don't think it is worthwhile to overcomplicate the protocol just to > provide a _possible_ (and maybe unlikely) failover solution. > > I like the algorithm for clients and proxies to be dead simple: > > 1. Proxies prepend an address to the front of the R-R list. > 2. If a client receives a R-R in a request, it copies it to the Route > directly and then appends the Contact. > 3. If a client receives a R-R in a final response, it reverse copies > it to the Route and then appends the Contact. > 4. When a client sends a request, it pops the first route and then > uses it as the Request-URI. > > This algorithm is currently followed by multiple existing > implementations. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- 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 Fri Nov 17 07:10: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 HAA25328 for ; Fri, 17 Nov 2000 07:10:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C1684436D; Fri, 17 Nov 2000 06:09:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id E6EBF44368 for ; Fri, 17 Nov 2000 06:08:43 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id GAA25141; Fri, 17 Nov 2000 06:08:34 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id GAA29486; Fri, 17 Nov 2000 06:08:33 -0600 (CST) Received: from ericsson.com (kipe51.ki.sw.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id GAA21558; Fri, 17 Nov 2000 06:08:31 -0600 (CST) Message-ID: <3A151FBB.57D381CD@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: mranga@nist.gov, jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 13:08:28 +0100 Content-Transfer-Encoding: 7bit Just one brief comment. /sean Chris Harris wrote: > Ranga, > Thanks for the input! Comments below... > Regards, > Chris > > M. Ranganathan wrote: > > > > Chris Harris wrote: > > > > > Prompt SIP responses from the server under such circumstances are not > > a requirement of the spec (as far as I know). Hence, the way > > I understand it (correct me if I am wrong) it would be legal for the > > server to do a number of things under this scenario including just > > ignore the mangled header (and drop it silently) so this behavior > > is best left unspecified in JAIN-SIP (gives implementations the > > ability to choose to do whatever they want). > > > Is dropping the broken header the usual way to handle this case? Do any > SIP implementations keep the header and leave the header content as a > string? To be really "future proof", you should return the header content as is, even if it doesn't parse correctly (according to the parser's notion of correctness). Dropping it seems very wrong. > > Thanks. > > Regards, > > Ranga. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 07:23:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00418 for ; Fri, 17 Nov 2000 07:23:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C52134434E; Fri, 17 Nov 2000 06:23:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E9CD14433D for ; Fri, 17 Nov 2000 06:22:03 -0500 (EST) Received: from dynamicsoft.com (useraa50.ie.uudial.com [212.120.133.51]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA11391; Fri, 17 Nov 2000 07:24:11 -0500 (EST) Message-ID: <3A152298.2A25BEDF@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: mranga@nist.gov, jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 12:20:40 +0000 Content-Transfer-Encoding: 7bit Sean, If dropping the malformed header is considered wrong, then one solution in the JAIN context would be to use the generic Header class instead of the particular subclass, say FromHeader. But this assumes that the header is fully parsed before the object is created - if lazy-parsing is used the FromHeader will be created based on the header name - and the fact that the header content is malformed will not be discovered until the application attempts to access the various parts of the header. As an alternative, a JainSipParseException could be thrown by the get methods, and if one is thrown, the application must then call the getValue() method to get the string version of the malformed content? Chris Sean Olson wrote: > Just one brief comment. > /sean > > Chris Harris wrote: > > > Ranga, > > Thanks for the input! Comments below... > > Regards, > > Chris > > > > M. Ranganathan wrote: > > > > > > Chris Harris wrote: > > > > > > > > > > > Prompt SIP responses from the server under such circumstances are not > > > a requirement of the spec (as far as I know). Hence, the way > > > I understand it (correct me if I am wrong) it would be legal for the > > > server to do a number of things under this scenario including just > > > ignore the mangled header (and drop it silently) so this behavior > > > is best left unspecified in JAIN-SIP (gives implementations the > > > ability to choose to do whatever they want). > > > > > Is dropping the broken header the usual way to handle this case? Do any > > SIP implementations keep the header and leave the header content as a > > string? > > To be really "future proof", you should return the header content as is, > even if it doesn't parse correctly (according to the parser's notion of > correctness). Dropping it seems very wrong. > > > > Thanks. > > > Regards, > > > Ranga. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 17 07: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 HAA01348 for ; Fri, 17 Nov 2000 07:25:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E8CD44377; Fri, 17 Nov 2000 06:23:23 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 1401E4433D for ; Fri, 17 Nov 2000 06:22:12 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eAHCNQL22895 for ; Fri, 17 Nov 2000 17:53:26 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eAHCV5P02504 for ; Fri, 17 Nov 2000 18:01:11 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525699A.00443A13 ; Fri, 17 Nov 2000 17:55:13 +0530 X-Lotus-FromDomain: HSSBLR From: sudha@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <6525699A.00443963.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] SIP-loadgenerators Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 17 Nov 2000 17:55:11 +0530 Hi, Is anyone using a SIP-loadgenerator, to test sipserver applications.Can someone provide me info on this. Regards, N.Sudha _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 07:29: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 HAA02926 for ; Fri, 17 Nov 2000 07:29:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88BA044388; Fri, 17 Nov 2000 06:24:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 45EFB4433D for ; Fri, 17 Nov 2000 06:23:07 -0500 (EST) Received: from dynamicsoft.com (useraa50.ie.uudial.com [212.120.133.51]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA11399; Fri, 17 Nov 2000 07:25:21 -0500 (EST) Message-ID: <3A1522DE.C6F5F3F8@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jainsip@sun.com Cc: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] JAIN SIP - some other issues Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 17 Nov 2000 12:21:50 +0000 Content-Transfer-Encoding: 7bit A couple of other issues which need to be resolved are as follows: The equals() methods are currently over-ridden e.g. AcceptHeader has a method public boolean equals(AcceptHeader acceptHeader). Is this over-riding desirable, or would the original signature public boolean equals(object obj) be preferable? The JainSipFactory has replaced the JainIPFactory due to the number of SIP-specific create methods needed with interfaces. The JainSipFactory defines a generic createJainSipObject(...) method that takes a String (which is appended to the path name to give the fully qualified class name of the object to be created). This method throws a JainSipPeerUnavailableException if the class specified is not found. This exception extends JainSipException, and is therefore a checked exception. The question is whether the other create methods in the factory e.g. createAcceptHeader(...) should catch this exception (assume the JAIN SIP implementation will contain an AcceptHeader implementation), or throw it. I think it is reasonable to assume that an implementation will provide all the classes needed (otherwise they will fail the TCK), but the user may set the path name of the factory to a non-existent implementation, say com.nosuchcompany, or the implementation they wish to use may not be in the classpath. This would suggest that all create methods in the factory should throw the JainSipPeerUnavailableException. However, this will place a large burden on the application, since it will have to catch this exception every time it tries to create a header or message. My suggestion is to create a JainSipRuntimeException, and have JainSipPeerUnavailableException extend it. Would this be considered a reasonable solution? Regards, Chris Harris _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 08:22: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 IAA20486 for ; Fri, 17 Nov 2000 08:22:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE0294433D; Fri, 17 Nov 2000 07:22:07 -0500 (EST) 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 A40A144336 for ; Fri, 17 Nov 2000 07:21:49 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 17 Nov 2000 12:42:11 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-29) id MAA13403; Fri, 17 Nov 2000 12:42:09 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025699A.0045B8BD ; Fri, 17 Nov 2000 12:41:32 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Anders Kristensen Cc: Neil Deason , Sip List Message-ID: <8025699A.0045B6A1.00@marconicomms.com> Subject: Re: [SIP] new torture tests Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 12:41:10 +0000 I have a problem regarding the parsing of the contact line in 12C : Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone The accompanying text says that the 'user' parameter should be interpreted as being a contact-param and not a url-parameter; I believe the opposite is true if the BNF followed; here is why: The first line of the contact rule is: Contact = ("Contact" | "m") ":" ("*"|(1#((name-addr|addr-spec)*((";"contact-params)))) having decoded the keyword Contact, the rule is now looking for name-addr or addr-spec; as there is no display name or angled brackets then addr-spec is the next rule to decode. The rule for addr-spec is addr-spec = SIP-URL|URI which is matched perfectly by sip:+1-972-555-222@gw1.wcom.com;user=phone I do not see any reason why the decoding of the SIP-URL rule should stop before the parameters if they satisfy the url-parameter spec so therefore user=phone would belong to url-parameters and not contact-parameters which is probably intended. Now to the particular problem I see. Consider the following line Contact: sip:+1-972-555-2222@gw1.com.wcom;action=proxy Using the above logic , paramter action=proxy would satisfy the other-param spec in SIP-URL which is probably not what is intended. I think the safest approach is to use the name-addr format in all cases and then parameters which belong to url-parameters are placed inside the angled brackets and parameters which belong to contact-params are placed otside the brackets, thus Contact: ;action=proxy will always give desired behaviour. The above also applies to other headers such as To and From. Regards, K. Robinson. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 08:40: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 IAA28503 for ; Fri, 17 Nov 2000 08:40:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92C7144360; Fri, 17 Nov 2000 07:40:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id B7F3544336 for ; Fri, 17 Nov 2000 07:39:08 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V797MSQB; Fri, 17 Nov 2000 14:36:16 +0100 From: "Hisham Khartabil" To: "Keith Robinson" , "Anders Kristensen" Cc: "Neil Deason" , "Sip List" Subject: RE: [SIP] new torture tests Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <8025699A.0045B6A1.00@marconicomms.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 15:39:58 +0200 Content-Transfer-Encoding: 7bit Section 6.5 in the Bis: " The Contact, From and To header fields contain a URL. If the URL contains a comma, question mark or semicolon, the URL MUST be enclosed in angle brackets (< and >). Any URL parameters are contained within these brackets. If the URL is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URL parameters. " I think this should answer your query. Regards, Hisham Khartabil Hotsip Finland www.hotsip.com -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Keith Robinson Sent: Friday, 17 November 2000 2:41 PM To: Anders Kristensen Cc: Neil Deason; Sip List Subject: Re: [SIP] new torture tests I have a problem regarding the parsing of the contact line in 12C : Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone The accompanying text says that the 'user' parameter should be interpreted as being a contact-param and not a url-parameter; I believe the opposite is true if the BNF followed; here is why: The first line of the contact rule is: Contact = ("Contact" | "m") ":" ("*"|(1#((name-addr|addr-spec)*((";"contact-params)))) having decoded the keyword Contact, the rule is now looking for name-addr or addr-spec; as there is no display name or angled brackets then addr-spec is the next rule to decode. The rule for addr-spec is addr-spec = SIP-URL|URI which is matched perfectly by sip:+1-972-555-222@gw1.wcom.com;user=phone I do not see any reason why the decoding of the SIP-URL rule should stop before the parameters if they satisfy the url-parameter spec so therefore user=phone would belong to url-parameters and not contact-parameters which is probably intended. Now to the particular problem I see. Consider the following line Contact: sip:+1-972-555-2222@gw1.com.wcom;action=proxy Using the above logic , paramter action=proxy would satisfy the other-param spec in SIP-URL which is probably not what is intended. I think the safest approach is to use the name-addr format in all cases and then parameters which belong to url-parameters are placed inside the angled brackets and parameters which belong to contact-params are placed otside the brackets, thus Contact: ;action=proxy will always give desired behaviour. The above also applies to other headers such as To and From. Regards, K. Robinson. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 08:42:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29627 for ; Fri, 17 Nov 2000 08:42:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6475D44385; Fri, 17 Nov 2000 07:40:23 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from fepD.post.tele.dk (fepD.post.tele.dk [195.41.46.149]) by lists.bell-labs.com (Postfix) with ESMTP id 18E9244336 for ; Fri, 17 Nov 2000 07:39:13 -0500 (EST) Received: from dynamicsoft.com ([195.249.119.158]) by fepD.post.tele.dk (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001117133905.CXEW439.fepD.post.tele.dk@dynamicsoft.com>; Fri, 17 Nov 2000 14:39:05 +0100 Message-ID: <3A153515.BDE60D98@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Neil Deason , Sip List Subject: Re: [SIP] new torture tests References: <8025699A.0045B6A1.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 14:39:33 +0100 Content-Transfer-Encoding: 7bit Keith Robinson wrote: > > I have a problem regarding the parsing of the contact line in 12C : > > Contact: sip:+1-972-555-2222@gw1.wcom.com;user=phone > > The accompanying text says that the 'user' parameter should be interpreted as > being a contact-param and not a url-parameter; I believe the opposite is true if > the BNF followed; here is why: This goes back to that paragraph I was quoting... (bis-02 section 6.14): Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, semicolon, or question mark. Since the name-addr form is NOT used it follows that the addr-spec part does NOT contain a comma, semicolon, or question mark. Hence the parameter cannot belong to the SIP URL and so must belong to the Contact. The correct parsing is not captured in the grammar which is what makes this case tricky. > > The first line of the contact rule is: > > Contact = ("Contact" | "m") ":" > ("*"|(1#((name-addr|addr-spec)*((";"contact-params)))) > > having decoded the keyword Contact, the rule is now looking for name-addr or > addr-spec; as there is no display name or angled brackets then addr-spec is the > next rule to decode. > > The rule for addr-spec is > > addr-spec = SIP-URL|URI > > which is matched perfectly by > > sip:+1-972-555-222@gw1.wcom.com;user=phone > > I do not see any reason why the decoding of the SIP-URL rule should stop before > the parameters if they satisfy the url-parameter spec so therefore user=phone > would belong to url-parameters and not contact-parameters which is probably > intended. > > Now to the particular problem I see. Consider the following line > > Contact: sip:+1-972-555-2222@gw1.com.wcom;action=proxy > > Using the above logic , paramter action=proxy would satisfy the other-param spec > in SIP-URL which is probably not what is intended. The above logic is wrong. This example is OK. > > I think the safest approach is to use the name-addr format in all cases and then > parameters which belong to url-parameters are placed inside the angled brackets > and parameters which belong to contact-params are placed otside the brackets, > thus Absolutely. No discussion at all. The point of the torture tests, though, is to test those rarely used constructs and try to stress implementations. It's not a BCP. It would probably have been better if the grammer hadn't allowed the addr-spec form to begin with. -- 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 Nov 17 09:41: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 JAA26389 for ; Fri, 17 Nov 2000 09:41:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 32F9C44396; Fri, 17 Nov 2000 08:39:15 -0500 (EST) 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 B27C84434E for ; Fri, 17 Nov 2000 05:30:35 -0500 (EST) 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 RAA08971 for ; Fri, 17 Nov 2000 17:09:44 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA3D75 for ; Fri, 17 Nov 2000 16:51:16 +0530 Message-ID: <014101c04fc1$5f98b660$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: Subject: [SIP] ID extension of REFER MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 16 Nov 2000 17:05:50 +0530 Content-Transfer-Encoding: 7bit > Sorry I had more to add !! using 1xx class of responses gives more > information to the transferor as to the state of the TT ... infact a lot of > applications (typically voice mail systems) usually support a feature called > "transfer to ringing", wherein, all they want to know is if the transfer > target is Idle and would want to complete the transfer if the TT is idle. If > TT is busy, they end up abandoning transfers and putting the user back into > voice mail. Using the 1xx responses allows us to continue supporting such > applications as well. > > Venkatesh > > ----- Original Message ----- > From: "Venkatesh Venkataramanan" > To: "Sean Olson" > Cc: ; "Robert Sparks" > Sent: Thursday, November 16, 2000 4:02 PM > Subject: Re: [SIP] ID extension of REFER > > > > I agree. If REFER can be modified to accept any 1xx responses (the draft > > currently talks about a 100 response/200/400-600 class responses), this > new > > ID probably is not required. One could reuse the 1xx progress information > > for REFER. The biggest advantage I see with this draft is the is the > ability > > of the transferor to get out of the transfer session at any time (instead > of > > waiting for a final response). Model fits the traditional PSTN blind > > transfers better. > > > > Venkatesh > > ----- Original Message ----- > > From: "Sean Olson" > > To: "Rohan Mahy" > > Cc: > > Sent: Friday, November 17, 2000 3:32 PM > > Subject: Re: [SIP] ID extension of REFER > > > > > > > Hello, > > > > > > I am a little confused about the purpose of this I-D. The first question > > > that springs to mind is > > > why you don't use "183" for this purpose? The second question is whether > > > you > > > intend the 189 to lead to different timing than any other provisional > > > response? > > > (In other words, if the 189 does NOT cause different timing, than the > > > issue of a long > > > period (> 37 seconds) between the INVITE and 200 OK is not really > > > solved. I realize > > > this should be a very rare case.) > > > > > > /sean > > > > > > Rohan Mahy wrote: > > > > > > > Hi, > > > > > > > > I just submitted an ID for an extension to the REFER method that I > > > > discussed with Robert Sparks at Pittsburgh. Until it appears in the > > > > archive it is available at: > > > > > > > > ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-189-00.txt > > > > > > > > > > > > A SIP Extension: Informational Responses to the REFER method > > > > > > > > Abstract > > > > > > > > This document defines a SIP extension to the REFER method of the > > > > SIP Call Control Framework. This extension provides for the > > > > ability to convey information about the progress of the Referred > > > > request when that request is in a provisional state for a long > > > > period of time (many seconds or minutes). > > > > > > > > > > > > Comments welcome. > > > > > > > > thanks, > > > > -rohan > > > > > > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > 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 Nov 17 09:43: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 JAA27400 for ; Fri, 17 Nov 2000 09:43:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B01124439C; Fri, 17 Nov 2000 08:39:29 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from i3exchange.inin.com (mail.inter-intelli.com [204.180.46.4]) by lists.bell-labs.com (Postfix) with ESMTP id 3583244336 for ; Fri, 17 Nov 2000 06:56:42 -0500 (EST) Received: by i3exchange.inin.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 07:59:26 -0500 Message-ID: From: "Snyder, Duke" 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] SDP coder negotiation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 17 Nov 2000 07:59:19 -0500 In rfc 2543 bis-02, section 16.3, there is a example: Bell sends INVITE, sdp=coders 0, 3, 4, 5. Watson sends Trying..... Watson sends OK, sdp=coders 0 3. Bell sends ACK, no sdp. How do Bell and Watson determine what coder to use (0 or 3 are common - but which one) since there is no coder negotiation in RTP. Thanks, Duke _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 10:49: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 KAA29904 for ; Fri, 17 Nov 2000 10:49:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6B3334435C; Fri, 17 Nov 2000 09:49:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 8E1C74435C for ; Fri, 17 Nov 2000 09:48:02 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 17 Nov 2000 09:47:42 -0600 (CST) From: Billy Biggs To: "Snyder, Duke" Cc: SIP List Subject: Re: [SIP] SDP coder negotiation Message-ID: <20001117094742.A31480@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from Duke.Snyder@inin.com on Fri, Nov 17, 2000 at 07:59:19AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 09:47:42 -0600 Snyder, Duke (Duke.Snyder@inin.com): > Bell sends INVITE, sdp=coders 0, 3, 4, 5. > Watson sends OK, sdp=coders 0 3. > > How do Bell and Watson determine what coder to use (0 or 3 are common > - but which one) since there is no coder negotiation in RTP. They each choose whichever they prefer. Bell should be prepared to receive any of 0, 3, 4 or 5 and Watson should be prepared to receive either of 0 or 3. As well, they should note that the incoming codec can change at any point in time, and that the incoming RTP can come from any IP address, not just the one you are sending to. The media flow is not a two-way connection, it is two one-way connections. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 11: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 SMTP id LAA04976 for ; Fri, 17 Nov 2000 11:00:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71F42443A5; Fri, 17 Nov 2000 10:00:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 7EFF24439A for ; Fri, 17 Nov 2000 09:59:45 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for SIP@lists.bell-labs.com; Fri, 17 Nov 2000 09:59:38 -0600 (CST) From: Billy Biggs To: Bertil Engelholm Cc: SIP@lists.bell-labs.com, Jo Hornsby , Sean Olson , Jonathan Rosenberg Subject: Re: Record-Route (was Re: [SIP] Identification problem) Message-ID: <20001117095938.B31480@div8.net> References: <3A07C09B.DAC8B5E5@ericsson.com> <001b01c04976$80fa26a0$4e34c3c1@ubiquity.co.uk> <8uvdf9$9f$1@lux2.datacom-lab.uab.ericsson.se> <3A151F8A.5A07F210@uab.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A151F8A.5A07F210@uab.ericsson.se>; from Bertil.Engelholm@uab.ericsson.se on Fri, Nov 17, 2000 at 01:07:38PM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 09:59:38 -0600 Bertil Engelholm (Bertil.Engelholm@uab.ericsson.se): > The other proposals you have concerns me a little bit. Should we > really use an URI for this kind of data. It will probably work fine > but it's to much of a hack in my eyes. How about other types of URIs > in ROUTE ? It is not a hack: You are sending the request to some state object on a proxy so that it can update its state and then pass on the message. > As Jonathan pointed out some weeks ago there is no maddr parameter in > a TEL URL. So something needs to be done to ROUTE to handle these kind > of URLs. So some parameter needs to be added to RECORD-ROUTE and ROUTE > (e.g. named 'raddr' for route address). You're suggesting that a proxy can put as its Record-Route: --> R-R: ;raddr=proxy:5060 Future requests are now sent like this: --> MYMETHOD http://my.proxy.com/rec-route-state SIP/2.0 But IPly they are sent to the IP address proxy:5060 This is dangerous because: 1. The Request-URI is not routable by a transparent proxy in the middle. If some firewall proxy snarfs the message, unless it records the real IP destination and port, it won't be able to route it to the appropriate destination. This breaks the SIP model. 2. This gets confusing, since in this case it is an http URI, but you're not sending it over http. I think that supporting this gives a small benefit at the cost of more difficult implementation and non-compatibility with existing software. I don't believe it is worth it. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 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 MAA29254 for ; Fri, 17 Nov 2000 12:01:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 299984435A; Fri, 17 Nov 2000 11:01:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 7B46444353 for ; Fri, 17 Nov 2000 11:00:19 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA08893; Fri, 17 Nov 2000 11:00:10 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id LAA16779; Fri, 17 Nov 2000 11:00:10 -0600 (CST) Received: from ericsson.com (kipe51.ki.sw.ericsson.se [147.214.68.51]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA04365; Fri, 17 Nov 2000 11:00:08 -0600 (CST) Message-ID: <3A156414.1BF00857@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Bertil Engelholm , SIP@lists.bell-labs.com, Jo Hornsby , Jonathan Rosenberg Subject: Re: Record-Route (was Re: [SIP] Identification problem) References: <3A07C09B.DAC8B5E5@ericsson.com> <001b01c04976$80fa26a0$4e34c3c1@ubiquity.co.uk> <8uvdf9$9f$1@lux2.datacom-lab.uab.ericsson.se> <3A151F8A.5A07F210@uab.ericsson.se> <20001117095938.B31480@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: Fri, 17 Nov 2000 18:00:04 +0100 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > Bertil Engelholm (Bertil.Engelholm@uab.ericsson.se): > > > > As Jonathan pointed out some weeks ago there is no maddr parameter in > > a TEL URL. So something needs to be done to ROUTE to handle these kind > > of URLs. So some parameter needs to be added to RECORD-ROUTE and ROUTE > > (e.g. named 'raddr' for route address). > > You're suggesting that a proxy can put as its Record-Route: > --> R-R: ;raddr=proxy:5060 > > Future requests are now sent like this: > --> MYMETHOD http://my.proxy.com/rec-route-state SIP/2.0 > > But IPly they are sent to the IP address proxy:5060 > > This is dangerous because: > > 1. The Request-URI is not routable by a transparent proxy in the > middle. If some firewall proxy snarfs the message, unless it > records the real IP destination and port, it won't be able to route > it to the appropriate destination. This breaks the SIP model. > > 2. This gets confusing, since in this case it is an http URI, but > you're not sending it over http. > > I think that supporting this gives a small benefit at the cost of more > difficult implementation and non-compatibility with existing software. > > I don't believe it is worth it. > I believe it is. The tel: URI is a good case for this. There are three pieces of information that the Record-Route: needs to convey: 1) What do you put in the Request-URI? 2) Where (IP address/port) do I send the message? 3) What is the context/state that the proxy associated with this RR? The first item should be the addr-spec in the RR. The second item should be separate and should be a parameter of the RR (not of the addr-spec) The third item can either be implied by the first item (provided it is honored and not overriden by the Contact:) or it can be provided by a parameter of the RR. Is this backwards compatible with RFC2543? No, because of the second item which is not a maddr parameter of the URI. This could be rectified for SIP URIs by *both* adding an maddr parameter to the SIP URI and adding a new raddr parameter to the Record-Route: Record-Route: ;raddr=proxy13.money.com I don't see a clean way to provide backwards compatibility to RFC2543. This is mainly because the mechanisms in RFC2543 are broken in subtle ways. my two cents /sean -- Sean Olson Ericsson Inc. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 12:44: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 MAA16793 for ; Fri, 17 Nov 2000 12:44:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5795A44390; Fri, 17 Nov 2000 11:44:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3725844353 for ; Fri, 17 Nov 2000 11:43:16 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA14742 for ; Fri, 17 Nov 2000 12:45:32 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2Y0WZ>; Fri, 17 Nov 2000 12:41:31 -0500 Message-ID: From: Jonathan Rosenberg 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] New I-D on Application Server Components Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 17 Nov 2000 12:41:23 -0500 Folks, I've just submitted the following I-D to the archives: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-app-component s-00.txt The draft describes an architecture for building large, complex applications by breaking them into components. Examples of components are IVR servers, conferencing servers, messaging servers, TTS servers, and so on. The draft shows how SIP (along with HTTP in some cases) represents the ideal interface between these components. The draft also discusses collection of DTMF in this architecture, and how to unify it with speech recognition and web input for service stimulus. 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 Nov 17 13:29:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03691 for ; Fri, 17 Nov 2000 13:29:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E62544391; Fri, 17 Nov 2000 12:29:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 8230244353 for ; Fri, 17 Nov 2000 12:28:52 -0500 (EST) 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 KAA29873; Fri, 17 Nov 2000 10:28:49 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAA68263; Fri, 17 Nov 2000 10:28:11 -0800 (PST) Message-Id: <4.1.20001117102008.00a85c50@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Sean Olson From: Rohan Mahy Subject: Re: [SIP] ID extension of REFER Cc: sip@lists.bell-labs.com In-Reply-To: <3A15023A.5CA44703@ericsson.com> References: <4.1.20001116151548.00cc2850@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 10:28:23 -0800 At 02:02 AM 11/17/00 , Sean Olson wrote: >Hello, > >I am a little confused about the purpose of this I-D. The first question >that springs to mind is >why you don't use "183" for this purpose? the semantics of 183 already means something different, and i did not think I could overload those semantics cleanly. >The second question is whether you >intend the 189 to lead to different timing than any other provisional >response? A sends REFER to B B sends INVITE to C A would get 189s any time B got provisionals from C. If C just 200 OKs B's INVITE, no 189s are sent. If C sends 180 or 183 and answers right away, A still gets a 189. If you don't need the information you can ignore it. thanks, -rohan >(In other words, if the 189 does NOT cause different timing, than the >issue of a long > period (> 37 seconds) between the INVITE and 200 OK is not really >solved. I realize > this should be a very rare case.) > >/sean > >Rohan Mahy wrote: > >> Hi, >> >> I just submitted an ID for an extension to the REFER method that I >> discussed with Robert Sparks at Pittsburgh. Until it appears in the >> archive it is available at: >> >> ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-189-00.txt >> >> >> A SIP Extension: Informational Responses to the REFER method >> >> Abstract >> >> This document defines a SIP extension to the REFER method of the >> SIP Call Control Framework. This extension provides for the >> ability to convey information about the progress of the Referred >> request when that request is in a provisional state for a long >> period of time (many seconds or minutes). >> >> >> Comments welcome. >> >> thanks, >> -rohan >> >> > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 13:51:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12999 for ; Fri, 17 Nov 2000 13:51:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 87F3F443B6; Fri, 17 Nov 2000 12:51:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 78A7D443B5 for ; Fri, 17 Nov 2000 12:50:15 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id NAA03327; Fri, 17 Nov 2000 13:45:01 -0500 (EST) Message-ID: <3A157DD2.3C5CE9E7@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: Sean Olson , jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <3A152298.2A25BEDF@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------468E1B423FAF351B4D1D4D53" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 17 Nov 2000 13:49:54 -0500 --------------468E1B423FAF351B4D1D4D53 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 I think even a lazy parser needs to look at just keyword that identifies the header type (i.e. from: to: etc.) immediately. If no keyword matches, then the header is unrecognized and the mechanism to deal with unrecognized headers should be invoked promptly (thus allowing an implementation to extend SIP in a well architected fashion). On the other hand, if there is a matching header identifier, then there is no need to parse the rest of the header immediately. It can be deferred until the application explicitly requests the JAIN-SIP implementation to do so. Thus I think rather than handle this case with just returning a header type like general header, you may wish to consider an event mechanism that would invoke a handler for unsupported header (or throw an exception if you prefer). What I meant below by "dropping it" is not the parser discarding the header but an application ( say a proxy server) discarding the header that *is* of one of the types defined in the RFC but does not parse correctly. It is actually somewhat tricky to insist that an application be required to respond when a message contains a mangled header, as the parser must be able to parse enough of the header to construct a meaningful response (and know whom to respond to). It appears that the thing to do under these circumstances would be to make responses to mangled messages optional. (Of course "good" implementations will always try to respond promptly even under erroneous conditions). One clarification that Chris could help me with: Say I buy a JAIN-SIP proxy server and I want to write an extension. Ideally, I would like to extend the proxy server without touching its code. How could this be done (i.e. what mechanisms have you built in) with what you have designed ? (I am not claiming it cant be done-- just that I don't understand how to do it. ) Regards, Ranga. Chris Harris wrote: > Sean, > > If dropping the malformed header is considered wrong, then one solution in > the JAIN context would be to use the generic Header class instead of the > particular subclass, say FromHeader. But this assumes that the header is > fully parsed before the object is created - if lazy-parsing is used the > FromHeader will be created based on the header name - and the fact that the > header content is malformed will not be discovered until the application > attempts to access the various parts of the header. > > As an alternative, a JainSipParseException could be thrown by the get > methods, and if one is thrown, the application must then call the getValue() > method to get the string version of the malformed content? > > Chris > > Sean Olson wrote: > > > Just one brief comment. > > /sean > > > > Chris Harris wrote: > > > > > Ranga, > > > Thanks for the input! Comments below... > > > Regards, > > > Chris > > > > > > M. Ranganathan wrote: > > > > > > > > Chris Harris wrote: > > > > > > > > > > > > > > > > > Prompt SIP responses from the server under such circumstances are not > > > > a requirement of the spec (as far as I know). Hence, the way > > > > I understand it (correct me if I am wrong) it would be legal for the > > > > server to do a number of things under this scenario including just > > > > ignore the mangled header (and drop it silently) so this behavior > > > > is best left unspecified in JAIN-SIP (gives implementations the > > > > ability to choose to do whatever they want). > > > > > > > Is dropping the broken header the usual way to handle this case? Do any > > > SIP implementations keep the header and leave the header content as a > > > string? > > > > To be really "future proof", you should return the header content as is, > > even if it doesn't parse correctly (according to the parser's notion of > > correctness). Dropping it seems very wrong. > > > > > > Thanks. > > > > Regards, > > > > Ranga. > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------468E1B423FAF351B4D1D4D53 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I think even a lazy parser needs to look at just keyword that identifies the header type (i.e. from: to: etc.)  immediately.  If no keyword matches, then the header is unrecognized and the mechanism to deal with unrecognized headers should be invoked promptly (thus allowing an implementation to extend SIP in a well architected fashion). On the other hand, if there is a matching  header identifier,  then there is no need to parse the rest of the header immediately. It can be deferred until the application explicitly requests the JAIN-SIP implementation to do so. Thus I think rather than handle this case with just returning a header type like general header, you may wish to consider an event mechanism that would invoke a handler for unsupported header (or throw an exception if you prefer).

What I meant below by "dropping it" is not  the parser discarding the header but  an application ( say  a proxy server)  discarding the header that  *is*  of one of the types defined in the RFC but does not parse correctly.  It is actually somewhat tricky to insist that an application be required to respond when a message contains a mangled header,   as the parser  must be able to parse enough of the header to construct a meaningful response (and know whom to respond to).  It appears that the thing to do under these circumstances would be to make responses to mangled messages optional.  (Of course "good" implementations will always try to respond promptly even under erroneous conditions).

One clarification that Chris could help me with:  Say I buy a JAIN-SIP  proxy server and I want to write an extension. Ideally, I would like to extend the proxy server without touching its code. How could this be done (i.e. what mechanisms have you built in)  with what you have designed ? (I am not claiming it cant be done-- just that I don't understand how to do it. )
 

Regards,
 

Ranga.

Chris Harris wrote:

Sean,

If dropping the malformed header is considered wrong, then one solution in
the JAIN context would be to use the generic Header class instead of the
particular subclass, say FromHeader. But this assumes that the header is
fully parsed before the object is created - if lazy-parsing is used the
FromHeader will be created based on the header name - and the fact that the
header content is malformed will not be discovered until the application
attempts to access the various parts of the header.

As an alternative, a JainSipParseException could be thrown by the get
methods, and if one is thrown, the application must then call the getValue()
method to get the string version of the malformed content?

Chris

Sean Olson wrote:

> Just one brief comment.
> /sean
>
> Chris Harris wrote:
>
> > Ranga,
> > Thanks for the input! Comments below...
> > Regards,
> > Chris
> >
> > M. Ranganathan wrote:
> > >
> > > Chris Harris wrote:
> > >
>
> <snip>
>
> >
> > > Prompt SIP responses from the server under such circumstances are not
> > > a requirement of the spec (as far as I know).  Hence, the way
> > > I understand it (correct me if I am wrong)  it would be legal for the
> > > server to do a number of things under this scenario including just
> > > ignore the mangled header  (and drop it silently)  so this behavior
> > > is  best left unspecified in JAIN-SIP (gives implementations the
> > > ability to choose to do whatever they want).
> > >
> > Is dropping the broken header the usual way to handle this case? Do any
> > SIP implementations keep the header and leave the header content as a
> > string?
>
> To be really "future proof", you should return the header content as is,
> even if it doesn't parse correctly (according to the parser's notion of
> correctness). Dropping it seems very wrong.
>
> > > Thanks.
> > > Regards,
> > > Ranga.
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------468E1B423FAF351B4D1D4D53-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 16:00: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 QAA10028 for ; Fri, 17 Nov 2000 16:00:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 676B844353; Fri, 17 Nov 2000 15:00:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 67B8C44352 for ; Fri, 17 Nov 2000 14:59:30 -0500 (EST) Received: from athletics ([63.110.3.140]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id QAA17192 for ; Fri, 17 Nov 2000 16:01:44 -0500 (EST) From: "Steve Donovan" To: "SIP" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Put Your Systems to the Test with the Experience of dynamicsoft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 17 Nov 2000 14:57:42 -0600 Content-Transfer-Encoding: 7bit It's clear that interoperability is on the critical path to your success. You can tap into dynamicsoft's experience and expertise by testing your SIP systems with dynamicsoft's proxy & location servers. To join the community of users who already are benefitting from testing with us, go to www.dynamicsoft.com and click "Send a request" in the "Spotlights" message at the bottom of the page. --- Steven R. Donovan Architect dynamicsoft mailto:sdonovan@dynamicsoft.com 5100 Tennyson Parkway sip:sdonovan@sip.dynamicsoft.com Plano, Texas 75025 tel:+1-972-473-5469 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 Nov 17 17:06:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12318 for ; Fri, 17 Nov 2000 17:06:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C5D34433F; Fri, 17 Nov 2000 16:06:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 5137C44336 for ; Fri, 17 Nov 2000 16:05:33 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 17 Nov 2000 16:05:26 -0600 (CST) From: Billy Biggs To: SIP List Message-ID: <20001117160526.B31680@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] Replaces Header 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, 17 Nov 2000 16:05:26 -0600 Hi, We've written a brief draft describing the use of a new header, Replaces, based slightly on the spirit of the old one from sip-cc-01. The purpose of this extension is to provide a method for allowing an active call-leg to be replaced by a new incoming call-leg for the purposes of call handoff using REFER. It is intended to provide a reasonable amount of backwards compatibility and also be easy to understand. It is available online at: http://www.sip-happens.com/replaces/draft-biggs-sip-replaces-00.txt -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 17 18:14:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14522 for ; Fri, 17 Nov 2000 18:14:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0211644359; Fri, 17 Nov 2000 17:14:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A8D6F44357 for ; Fri, 17 Nov 2000 17:13:08 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA18431; Fri, 17 Nov 2000 18:15:22 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2ZAPC>; Fri, 17 Nov 2000 18:11:21 -0500 Message-ID: From: Jonathan Rosenberg To: "'sip-events@egroups.com'" Cc: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP for Presence Bof Meeting at San Diego Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 17 Nov 2000 18:11:18 -0500 Folks, I'm pleased to announce that the SIP for presence and instant messaging work is going to have a BoF session at the next IETF. The agenda has not been updated yet to reflect it, but the meeting will replace one hour of the current IMPP slot on Monday. The proposed agenda is: The SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) BoF session will investigate forming a working group to standardize on SIP for presence as a transfer protocol supporting within the Common Format for Presence and Instant Messaging (CPIM) framework. Suggested reading: SIP for presence: --------------- http://search.ietf.org/internet-drafts/draft-rosenberg-impp-im-00.txt http://search.ietf.org/internet-drafts/draft-rosenberg-impp-presence-00.txt http://search.ietf.org/internet-drafts/draft-rosenberg-impp-qauth-00.txt CPIM: ----- http://www.ietf.org/rfc/rfc2779.txt http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-00.txt SIP Events: ---------- http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-01.t xt Proposed agenda: 1. Update on status on IMPP and SIP for presence efforts 2. Quick overview of CPIM 3. Quick overview of SIP for IM and Presence 3. Relationship of SIP for presence and SIP events work 4. Charter bashing a. division of work between this group and sip group b. specific deliverables 5. Open issues in SIP for presence work Looking forward to seeing everyone in San Diego, 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 Nov 17 18:27:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14690 for ; Fri, 17 Nov 2000 18:27:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4DC0844351; Fri, 17 Nov 2000 17:27:08 -0500 (EST) 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 A3FB744341 for ; Fri, 17 Nov 2000 17:26:47 -0500 (EST) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Fri, 17 Nov 2000 15:24:11 -0800 Message-ID: <070c01c050ee$40a99cf0$3a0514ac@sbarber2k> From: "Simon Barber" To: "Billy Biggs" Cc: "'Sip@Lists. Bell-Labs. Com'" , "Kyle Granger" References: <20001117094742.A31480@div8.net> Subject: Re: [SIP] SDP coder negotiation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 15:29:38 -0800 Content-Transfer-Encoding: 7bit Billy Biggs: > Snyder, Duke (Duke.Snyder@inin.com): > > > Bell sends INVITE, sdp=coders 0, 3, 4, 5. > > Watson sends OK, sdp=coders 0 3. > > > > How do Bell and Watson determine what coder to use (0 or 3 are common > > - but which one) since there is no coder negotiation in RTP. > > They each choose whichever they prefer. Bell should be prepared to > receive any of 0, 3, 4 or 5 and Watson should be prepared to receive > either of 0 or 3. > > As well, they should note that the incoming codec can change at any > point in time, and that the incoming RTP can come from any IP address, > not just the one you are sending to. > > The media flow is not a two-way connection, it is two one-way > connections. They should also be able to receive multiple audio streams, with different SSRC at a single RTP port. Most implementations out there today do not conform to the spec and will not handle this. Could I do a quick survey of implementations out there - what RTP functionality do you support (should this be in the bake-off torture test?): 1) changing codecs on the fly 2) receiving packets that contain different amounts of audio 3) handling RTCP at all 4) receiving RTP from any address 5) multiple audio streams (how many?) 6) SSRC clash resolution 7) multicast any others? Our implementation will support all of the above, and 100s of audio streams. Simon Barber _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 18 01:15: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 BAA23582 for ; Sat, 18 Nov 2000 01:15:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 61B5B44341; Sat, 18 Nov 2000 00:15:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.mantraonline.com (unknown [202.56.230.13]) by lists.bell-labs.com (Postfix) with ESMTP id 1EC8044336 for ; Sat, 18 Nov 2000 00:14:01 -0500 (EST) Received: from bigboy ([202.56.197.25]) by mail.mantraonline.com (Netscape Messaging Server 4.1) with SMTP id G48BC700.OKK; Sat, 18 Nov 2000 11:33:44 -0500 Message-ID: <003201c05125$b222f890$1200a8c0@bigboy> From: "farhan" To: , "Chris Harris" Cc: , , , References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] a stupid question on 3way handshake Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 18 Nov 2000 11:36:14 +0530 Content-Transfer-Encoding: 7bit why do we have a 3 way handshake for INVITE? is an INVITE-Response not enough ? why? i do know some of the issue involved with a 2 way handshake. but can someone tell me about what are all the problems with just an INVITE-Response system (without needing an ACK) . - 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 Nov 18 01:28: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 BAA25357 for ; Sat, 18 Nov 2000 01:28:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 22A0944363; Sat, 18 Nov 2000 00:28:09 -0500 (EST) 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 EDCAD44357 for ; Sat, 18 Nov 2000 00:27:05 -0500 (EST) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Fri, 17 Nov 2000 22:24:29 -0800 Message-ID: <089201c05128$f83c0a80$3a0514ac@sbarber2k> From: "Simon Barber" To: "farhan" , , "Chris Harris" Cc: , , , References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> Subject: Re: [SIP] a stupid question on 3way handshake MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 17 Nov 2000 22:29:56 -0800 Content-Transfer-Encoding: 7bit This is to do with the rather confusing conecpt of the SIP transaction, and reliability. In my opinion we need a document that clearly documents this, since it is one of the most confusing aspects of the protocol - and it got that way because the protocol has 'evolved'. The INVITE retransmission will stop on receiving a provisional response, so the ACK is needed to ensure the reliability (and stop retransmission of) the final response. (correct me if I'm wrong please!) Simon. ----- Original Message ----- From: "farhan" To: ; "Chris Harris" Cc: ; ; ; Sent: Friday, November 17, 2000 10:06 PM Subject: [SIP] a stupid question on 3way handshake > why do we have a 3 way handshake for INVITE? is an INVITE-Response not > enough ? why? > i do know some of the issue involved with a 2 way handshake. but can someone > tell me about what are all the problems with just an INVITE-Response system > (without needing an ACK) . > > - 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 Nov 18 01:55: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 BAA28941 for ; Sat, 18 Nov 2000 01:55:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9BF944346; Sat, 18 Nov 2000 00:55:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from studentmail.newcastle.edu.au (yakamoto.newcastle.edu.au [134.148.4.7]) by lists.bell-labs.com (Postfix) with ESMTP id 6772D44336 for ; Sat, 18 Nov 2000 00:54:41 -0500 (EST) Received: from one ([134.148.10.213]) by yakamoto.newcastle.edu.au (PMDF V5.2-32 #35876) with ESMTP id <0G47006ATKIVDZ@yakamoto.newcastle.edu.au> for sip@lists.bell-labs.com; Sat, 18 Nov 2000 17:54:32 +1100 (EST) From: Stuart Bargon Subject: RE: [SIP] a stupid question on 3way handshake In-reply-to: <003201c05125$b222f890$1200a8c0@bigboy> To: sip@lists.bell-labs.com Reply-To: c9314310@studentmail.newcastle.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 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: Sat, 18 Nov 2000 17:57:32 +1100 Content-Transfer-Encoding: 7BIT I would suggest looking into the solutions developed to get around the two armies problem. The classic computer science problem goes something like this: Two generals with two armies are besieging a city, each on the opposite side of the city. They have very good clocks. They communicate by messengers that may be killed on the way. The generals need to agree on a time when to attack simultaneously the city. If they attack separately, they will lose. If together they will win. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of farhan Sent: Saturday, 18 November 2000 5:06 PM To: discussion@sipforum.org; Chris Harris Cc: mranga@nist.gov; jainsip@sun.com; sip@lists.bell-labs.com; discussion@sipforum.org Subject: [SIP] a stupid question on 3way handshake why do we have a 3 way handshake for INVITE? is an INVITE-Response not enough ? why? i do know some of the issue involved with a 2 way handshake. but can someone tell me about what are all the problems with just an INVITE-Response system (without needing an ACK) . - 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 Nov 18 02:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05944 for ; Sat, 18 Nov 2000 02:29:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A2AC444357; Sat, 18 Nov 2000 01:29:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.mantraonline.com (unknown [202.56.230.13]) by lists.bell-labs.com (Postfix) with ESMTP id 4F51D44336 for ; Sat, 18 Nov 2000 01:28:51 -0500 (EST) Received: from bigboy ([202.56.197.25]) by mail.mantraonline.com (Netscape Messaging Server 4.1) with SMTP id G48ET600.5UK; Sat, 18 Nov 2000 12:48:42 -0500 Message-ID: <001101c05130$2b2578d0$1200a8c0@bigboy> From: "farhan" To: "Simon Barber" , , "Chris Harris" Cc: , , , References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> <089201c05128$f83c0a80$3a0514ac@sbarber2k> Subject: Re: [SIP] a stupid question on 3way handshake MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 18 Nov 2000 12:51:09 +0530 Content-Transfer-Encoding: 7bit well simon i am glad that someone shares the confusion. is dr. rosenberg on the list? i would love to hear from him on why the protocol got that way. > This is to do with the rather confusing conecpt of the SIP transaction, and > reliability. In my opinion we need a document that clearly documents this, > since it is one of the most confusing aspects of the protocol - and it got > that way because the protocol has 'evolved'. > > The INVITE retransmission will stop on receiving a provisional response, so > the ACK is needed to ensure the reliability (and stop retransmission of) the > final response. > > (correct me if I'm wrong please!) > > Simon. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 18 06:25: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 GAA07167 for ; Sat, 18 Nov 2000 06:25:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71A6444365; Sat, 18 Nov 2000 05:25:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 4147C44336 for ; Sat, 18 Nov 2000 05:24:46 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sat, 18 Nov 2000 05:24:34 -0600 (CST) From: Billy Biggs To: farhan Cc: SIP List Subject: Re: [SIP] a stupid question on 3way handshake Message-ID: <20001118052434.A32315@div8.net> References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <003201c05125$b222f890$1200a8c0@bigboy>; from farhan@hotfoon.com on Sat, Nov 18, 2000 at 11:36:14AM +0530 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 18 Nov 2000 05:24:34 -0600 farhan (farhan@hotfoon.com): > why do we have a 3 way handshake for INVITE? is an INVITE-Response not > enough ? why? > i do know some of the issue involved with a 2 way handshake. but can > someone tell me about what are all the problems with just an > INVITE-Response system (without needing an ACK) . I see two reasons why an ACK system is useful: 1. Forking. Remember that an initial request creates many call legs. Say that A sends a request to a proxy which forks in parallel to three locations: __ __ A /\ ---------> Proxy -----------> /\ B 200 OK / T:u@p;tag=5 SOMEMETHOD \ __ T:u@p ---------> /\ C 200 OK / T:u@p;tag=6 F:A;tag=4 \ __ -------> /\ D 200 OK / T:u@p;tag=7 Say all three answer the request at the same time with a 200 OK. We now have created three call legs: A-B (4-5), A-C (4-6), and A-D (4-7). Consider an unreliable transport (UDP). How do we ensure that A receives all three of these responses? The HTTP request-response model was not built to handle forking. One solution is to reliably transmit final responses. Each of B, C, and D can retransmit their response until they get an acknowledgement that someone actually got it. This is really a hack to the model, and you get some weird interactions: For example, in SIP you must retransmit final responses to INVITEs even when used over TCP! SIP decided that this stronger form of reliability is only useful for INVITE requests. It is critical for INVITE that all successful responses are received: otherwise we would get mysterious calls where one end thinks it's connected, but the other end never got the response. So, INVITE is treated as a big special case where responses are retransmitted until they hear an ACK. Unfortunately, this means that requests such as MESSAGE cannot take full advantage of the forking capabilities of SIP, since you cannot reliably tell how many endpoints received a forked request. Another problem method is SUBSCRIBE. Consequently, in order to build a deterministic system proxies should only parallel fork INVITEs, and wait for confirmation of a CANCEL before trying another branch of a non-INVITE sequential fork. 2. Optimization. The assumption in SIP is that INVITE transactions take a long time, while everything else is pretty much immediate. So, in order to optimize our flow, we retransmit the INVITE until we hear a provisional response, and then wait for the remote end to retransmit its final response. Unfortunately, this assumption is now false, and long-outstanding requests such as REFER must be continuously retransmitted to poll for the response when used over UDP. The main problem is trying to use the request/response model with the forking concept. If I were redesigning SIP, I would clean things up by making every transaction a 3-way handshake for protection. I guess you would also want to fix the retransmissions over TCP thing too. Ugh. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 18 07: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 HAA07726 for ; Sat, 18 Nov 2000 07:39:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 03D1044382; Sat, 18 Nov 2000 06:39:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.mantraonline.com (unknown [202.56.230.13]) by lists.bell-labs.com (Postfix) with ESMTP id 776C34437F for ; Sat, 18 Nov 2000 06:37:43 -0500 (EST) Received: from bigboy ([202.56.197.13]) by mail.mantraonline.com (Netscape Messaging Server 4.1) with SMTP id G48SVQ00.H8X; Sat, 18 Nov 2000 17:52:38 -0500 Message-ID: <000a01c0515a$a2777c60$1200a8c0@bigboy> From: "farhan" To: "Billy Biggs" Cc: "SIP List" References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> <20001118052434.A32315@div8.net> Subject: Re: [SIP] a stupid question on 3way handshake MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 18 Nov 2000 17:53:36 +0530 Content-Transfer-Encoding: 7bit > I see two reasons why an ACK system is useful: > > 1. Forking. Remember that an initial request creates many call legs. > Say that A sends a request to a proxy which forks in parallel to > three locations: > 2. Optimization. The assumption in SIP is that INVITE transactions take > a long time, while everything else is pretty much immediate. So, in > order to optimize our flow, we retransmit the INVITE until we hear a > provisional response, and then wait for the remote end to retransmit > its final response. > Unfortunately, this assumption is now false, and long-outstanding > requests such as REFER must be continuously retransmitted to poll for > the response when used over UDP. yes billy, forking is out of question without an ACKnowledgement. thanks for pointing this out. however, as forking is not an essential behaviour, couldn't it have moved away to be invoked only under certain conditions like Requires:acknowledgment. ? TCP/IP does a three way handshake too. it however has very different reasons for the handshake. TCP/IP's three way handshake has been called 'necessary and sufficient' by late richard stevens. tcp/ip handshake is not for a transaction but for a stream creation. therefore, the starting sequences have to be acknowlegded by both ends. There are actual two two way handshakes in tcp/ip, called end point sends a syn and gets and acknowledgement, then the called party sends syn and gets an acknowledgement. The four way handshake is merged into a three way handshake by riding the called party syn and ack into a single packet. However, that is no parallel for SIP as I see it. I am wondering if there are also issues of call parameter negotiation that require (or get enhanced) by a three way handshake _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 18 08:07: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 IAA08004 for ; Sat, 18 Nov 2000 08:07:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 038C54437F; Sat, 18 Nov 2000 07:07:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 9887C44336 for ; Sat, 18 Nov 2000 07:06:57 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sat, 18 Nov 2000 07:06:43 -0600 (CST) From: Billy Biggs To: farhan Cc: SIP List Subject: Re: [SIP] a stupid question on 3way handshake Message-ID: <20001118070643.A32698@div8.net> References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> <20001118052434.A32315@div8.net> <000a01c0515a$a2777c60$1200a8c0@bigboy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <000a01c0515a$a2777c60$1200a8c0@bigboy>; from farhan@hotfoon.com on Sat, Nov 18, 2000 at 05:53:36PM +0530 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 18 Nov 2000 07:06:43 -0600 farhan (farhan@hotfoon.com): > yes billy, forking is out of question without an ACKnowledgement. > thanks for pointing this out. however, as forking is not an essential > behaviour, couldn't it have moved away to be invoked only under > certain conditions like Requires:acknowledgment. ? Nope. There is no way to tell if a request will fork, and for security reasons the proxy server may not wish to disclose that the call forked to multiple locations. > [...] tcp/ip handshake is not for a transaction but for a stream > creation. therefore, the starting sequences have to be acknowlegded by > both ends. [...] Right, but in SIP you can setup a signalling connection (the parallel to a TCP/IP stream) using any method, not just INVITE. So, as you noted, setup of a SIP connection definitely does not require a 3-way handshake. It's just that INVITE needs to be more robust and responsive. > I am wondering if there are also issues of call parameter negotiation > that require (or get enhanced) by a three way handshake Not really. A client can delay sending a session description by not sending one in the INVITE and later sending it in the ACK, but that is simply a convenient optimization. In an INVITE transaction there are only ever two session descriptions, one for each end. For an API, the ACK is only to stop retransmissions, there is no need to have a concept of a 3-way handshake. One thing I forgot to mention: another reason why INVITE needs to have this special mechanism is to ensure speedy call setup. When the called party picks up their phone the response is retransmitted to help setup the call as quick as possible. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 18 08:52: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 IAA08385 for ; Sat, 18 Nov 2000 08:52:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34C0344398; Sat, 18 Nov 2000 07:52:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 4AD1744336 for ; Sat, 18 Nov 2000 07:51:35 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA23826; Sat, 18 Nov 2000 08:51:28 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA25090; Sat, 18 Nov 2000 08:51:25 -0500 (EST) Message-ID: <3A16B47E.819A7F53@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: farhan , SIP List Subject: Re: [SIP] a stupid question on 3way handshake References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> <20001118052434.A32315@div8.net> <000a01c0515a$a2777c60$1200a8c0@bigboy> <20001118070643.A32698@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: Sat, 18 Nov 2000 08:55:26 -0800 Content-Transfer-Encoding: 7bit The speedy call setup is the main (and motivating) reason. The only other alternative (with an unreliable transport) would have been to have a separate, callee-initiated transaction that says "I accept the call". All of this motivation, by the way, is contained in the spec in the section on transport. The reason for not making other methods 3-way was to make them simpler and to reduce message count, something that our wireless friends are very worried about. The ACK does allow to delay the session description, which is useful in some scenarios (some versions of H.323 interoperation, for example), but that by itself is mostly a minor advantage. As usual, optimization yields complexity. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 18 09:28: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 JAA08598 for ; Sat, 18 Nov 2000 09:28:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2233B4439E; Sat, 18 Nov 2000 08:28:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.mantraonline.com (unknown [202.56.230.13]) by lists.bell-labs.com (Postfix) with ESMTP id E6CDA44336 for ; Sat, 18 Nov 2000 08:27:39 -0500 (EST) Received: from bigboy ([202.56.197.13]) by mail.mantraonline.com (Netscape Messaging Server 4.1) with SMTP id G48SST00.09S; Sat, 18 Nov 2000 17:50:53 -0500 Message-ID: <000901c0515a$641b9690$1200a8c0@bigboy> From: "farhan" To: "Billy Biggs" Cc: "SIP List" References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> <20001118052434.A32315@div8.net> Subject: Re: [SIP] a stupid question on 3way handshake MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 18 Nov 2000 17:44:18 +0530 Content-Transfer-Encoding: 7bit > I see two reasons why an ACK system is useful: > > 1. Forking. Remember that an initial request creates many call legs. > Say that A sends a request to a proxy which forks in parallel to > three locations: > 2. Optimization. The assumption in SIP is that INVITE transactions take > a long time, while everything else is pretty much immediate. So, in > order to optimize our flow, we retransmit the INVITE until we hear a > provisional response, and then wait for the remote end to retransmit > its final response. > Unfortunately, this assumption is now false, and long-outstanding > requests such as REFER must be continuously retransmitted to poll for > the response when used over UDP. yes billy, forking is out of question without an ACKnowledgement. thanks for pointing this out. however, as forking is not an essential behaviour, couldn't it have moved away to be invoked only under certain conditions like Requires:acknowledgment. ? TCP/IP does a three way handshake too. it however has very different reasons for the handshake. TCP/IP's three way handshake has been called 'necessary and sufficient' by late richard stevens. tcp/ip handshake is not for a transaction but for a stream creation. therefore, the starting sequences have to be acknowlegded by both ends. There are actual two two way handshakes in tcp/ip, called end point sends a syn and gets and acknowledgement, then the called party sends syn and gets an acknowledgement. The four way handshake is merged into a three way handshake by riding the called party syn and ack into a single packet. However, that is no parallel for SIP as I see it. I am wondering if there are also issues of call parameter negotiation that require (or get enhanced) by a three way handshake _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Nov 18 13:07: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 NAA10701 for ; Sat, 18 Nov 2000 13:07:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 74DBB443A6; Sat, 18 Nov 2000 12:07:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 0C79E44336 for ; Sat, 18 Nov 2000 12:06:55 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eAII6lt29141; Sat, 18 Nov 2000 19:06:47 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.34]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id UAA29512; Sat, 18 Nov 2000 20:06:46 +0200 (EET) Message-ID: <3A16C519.8A75A321@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: Henning Schulzrinne Cc: Billy Biggs , farhan , SIP List Subject: Re: [SIP] a stupid question on 3way handshake References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> <20001118052434.A32315@div8.net> <000a01c0515a$a2777c60$1200a8c0@bigboy> <20001118070643.A32698@div8.net> <3A16B47E.819A7F53@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 18 Nov 2000 20:06:17 +0200 Content-Transfer-Encoding: 7bit Hi, A 2-way handshake would lead to the following situation: A sends an INVITE to B and begin retransmitting it. After a while A gives up and stops retransmitting the INVITE. A thinks that there is no session established. At the same time (when A is giving up), B sends a 200 OK back. Since B observes that A has stopped retransmitting the INVITE the 200 OK in not retransmitted, B thinks that the session is established... A 3-way hand-shake helps synchronizing both ends during session establishment. Regards, Gonzalo Henning Schulzrinne wrote: > > The speedy call setup is the main (and motivating) reason. The only > other alternative (with an unreliable transport) would have been to have > a separate, callee-initiated transaction that says "I accept the call". > > All of this motivation, by the way, is contained in the spec in the > section on transport. The reason for not making other methods 3-way was > to make them simpler and to reduce message count, something that our > wireless friends are very worried about. The ACK does allow to delay the > session description, which is useful in some scenarios (some versions of > H.323 interoperation, for example), but that by itself is mostly a minor > advantage. > > As usual, optimization yields complexity. > > _______________________________________________ > 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 Sat Nov 18 15:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12279 for ; Sat, 18 Nov 2000 15:55:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 441064437B; Sat, 18 Nov 2000 14:55:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.mantraonline.com (unknown [202.56.230.13]) by lists.bell-labs.com (Postfix) with ESMTP id E809F44336 for ; Sat, 18 Nov 2000 14:54:37 -0500 (EST) Received: from bigboy ([202.56.197.10]) by mail.mantraonline.com (Netscape Messaging Server 4.1) with SMTP id G49FGB00.RP2; Sun, 19 Nov 2000 02:00:12 -0500 Message-ID: <001101c0519e$bfb867f0$1200a8c0@bigboy> From: "farhan" To: "Gonzalo Camarillo" , "Henning Schulzrinne" Cc: "Billy Biggs" , "SIP List" References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> <20001118052434.A32315@div8.net> <000a01c0515a$a2777c60$1200a8c0@bigboy> <20001118070643.A32698@div8.net> <3A16B47E.819A7F53@cs.columbia.edu> <3A16C519.8A75A321@lmf.ericsson.se> Subject: Re: [SIP] a stupid question on 3way handshake 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: Sun, 19 Nov 2000 02:02:44 +0530 Content-Transfer-Encoding: 7bit > A sends an INVITE to B and begin retransmitting it. After a while A > gives up and stops retransmitting the INVITE. A thinks that there is no > session established. > > At the same time (when A is giving up), B sends a 200 OK back. Since B > observes that A has stopped retransmitting the INVITE the 200 OK in not > retransmitted, B thinks that the session is established... imagine the samething happening on the ACK. Party B keeps sending 200 OK until it times out and just then Party A responds back with an ACK and considers that the session is established. No, that is not a solution we need an infinite way handshake in such a case. - 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 Nov 19 01:56: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 BAA27880 for ; Sun, 19 Nov 2000 01:56:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1D5904433A; Sun, 19 Nov 2000 00:56:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 347D244336 for ; Sun, 19 Nov 2000 00:55:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14199; Sun, 19 Nov 2000 01:57:07 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2ZGVN>; Sun, 19 Nov 2000 01:53:03 -0500 Message-ID: From: Jonathan Rosenberg To: "'farhan'" , Billy Biggs Cc: SIP List Subject: RE: [SIP] a stupid question on 3way handshake MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 01:52:47 -0500 Sorry for taking so long to respond to many mails on the list the past few weeks... I've been focusing on completing my dissertation... > -----Original Message----- > From: farhan [mailto:farhan@hotfoon.com] > Sent: Saturday, November 18, 2000 7:24 AM > To: Billy Biggs > Cc: SIP List > Subject: Re: [SIP] a stupid question on 3way handshake > > > > I see two reasons why an ACK system is useful: > > > > 1. Forking. Remember that an initial request creates many > call legs. > > Say that A sends a request to a proxy which forks in parallel to > > three locations: > > > 2. Optimization. The assumption in SIP is that INVITE > transactions take > > a long time, while everything else is pretty much > immediate. So, in > > order to optimize our flow, we retransmit the INVITE > until we hear a > > provisional response, and then wait for the remote end > to retransmit > > its final response. > > Unfortunately, this assumption is now false, and long-outstanding > > requests such as REFER must be continuously > retransmitted to poll for > > the response when used over UDP. > > yes billy, forking is out of question without an > ACKnowledgement. thanks for > pointing this out. I'm sorry, but this is not correct. Forking is fine for non-invite requests. It will result in reception of a single response (which is, IMHO, a very nice property), which is the best amongst all those received. Forking of non-INVITEs is therefore useful for requests where it isn't important to know how many places received the request; simply knowing the best response is adequate. As an example, consider a hypothetical new request called "EXIST" which checks whether there is a UA in the network that meets the specifications (along the lines of caller preferences) described in the request. This request can fork to check numerous locations, and a 200 indicates a match. In this case, the client doesn't care how many requests were ultimately delivered, or to whom. Just the answer matters. I would argue that SUBSCRIBE meets this criteria as well. The caller really doesn't care who many servers are going to be handling the subscription. So long as some server accepts it, and generates notifications for it, thats all that matters. Regarding the original question, my recollection of the main motivation of special handling for INVITE was that we believe it was the only request for whom a response may not arrive for a long time, as it required non-automated processing to answer. Speedy delivery of acceptance was another benefit. In hindsight, I would have removed this special treatment. One request, one final response. No ack. Handling cases like this one (where the "response" might not come for a while), is more readily handled using two sepate transactions in each direction. So, we would have a new request, called INITIATE (instead of INVITE). A 200 response is sent as soon as the request is received by a UAS. When the call is answered, an ACCEPT message is sent by the called party, and responded to immediately with a 200 OK upon receipt. Billy writes: Optimization. The assumption in SIP is that INVITE > transactions take > a long time, while everything else is pretty much > immediate. So, in > order to optimize our flow, we retransmit the INVITE until > we hear a > provisional response, and then wait for the remote end to > retransmit > its final response. > > Unfortunately, this assumption is now false, and long-outstanding > requests such as REFER must be continuously retransmitted > to poll for > the response when used over UDP. Actually, I have begun to think that refer treatment should follow the two-transaction model above. There is a serious problem otherwise. The issue is that the INVITE triggered by the REFER may take more than 32 seconds for an answer. If this happens, the REFER transaction will timeout before the INVITE it triggered completes. So, my proposal would be that REFER generates an immediate 200 OK if the recipient is willing to try to send the request. We can then have the recipient of REFER send a request in the reverse direction (we can debate whether this is NOTIFY or something else) once the triggered INVITE completes successfully. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 03:10: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 DAA00855 for ; Sun, 19 Nov 2000 03:10:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3D1904436E; Sun, 19 Nov 2000 02:07:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 4ABC644336 for ; Sun, 19 Nov 2000 02:06:28 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sun, 19 Nov 2000 02:06:14 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Robert Sparks , farhan , SIP List Subject: Re: [SIP] a stupid question on 3way handshake Message-ID: <20001119020614.A776@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Sun, Nov 19, 2000 at 01:52:47AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 02:06:14 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > [...] Forking of non-INVITEs is therefore useful for requests where it > isn't important to know how many places received the request; simply > knowing the best response is adequate. [...] > > I would argue that SUBSCRIBE meets this criteria as well. The caller > really doesn't care who many servers are going to be handling the > subscription. So long as some server accepts it, and generates > notifications for it, thats all that matters. It matters when trying to unsubscribe. To be intelligence- at-the-edges correct, an unsubscribe should be sent within the call-leg created by the original SUBSCRIBE. However, to be forking-safe, the unsubscribe should be sent to the orignal address which was subscribed to, without a tag. It is a minor complaint. I know that to keep my implementation clean, a SUBSCRIBE in my stack will create a single call leg, and any NOTIFYs received outside of that call leg will be given 481s. I don't buy the "[...] subscribers SHOULD be prepared to receive notifications with previously unknown tags in the "From" field [...]" argument. Oh well. > > The assumption in SIP is that INVITE transactions take a long time, > > while everything else is pretty much immediate. So, in order to > > optimize our flow, we retransmit the INVITE until we hear a > > provisional response, and then wait for the remote end to retransmit > > its final response. > > > > Unfortunately, this assumption is now false, and long-outstanding > > requests such as REFER must be continuously retransmitted to poll > > for the response when used over UDP. > > Actually, I have begun to think that refer treatment should follow the > two-transaction model above. There is a serious problem otherwise. The > issue is that the INVITE triggered by the REFER may take more than 32 > seconds for an answer. If this happens, the REFER transaction will > timeout before the INVITE it triggered completes. As well, there is no way to tell if the far end accepted the REFER and is processing it, or if it will eventually return a 501. Responding to REFER immediately helps with error checking. We would also be less likely to have to worry about multiple outstanding transactions on a call-leg. However, it is much more verbose, and a major change to the REFER draft. These were the two reasons I didn't suggest it earlier. I might submit a BYE/Also transfer draft if this proposal flies, or maybe advocate louder it be added to bis. Thoughts? > So, my proposal would be that REFER generates an immediate 200 OK if > the recipient is willing to try to send the request. We can then have > the recipient of REFER send a request in the reverse direction (we can > debate whether this is NOTIFY or something else) once the triggered > INVITE completes successfully. I'm all for it. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 05:52:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08061 for ; Sun, 19 Nov 2000 05:52:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AA5F44380; Sun, 19 Nov 2000 04:52:09 -0500 (EST) 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 AEA9D44336 for ; Sun, 19 Nov 2000 04:51:31 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eAJApHD25646; Sun, 19 Nov 2000 11:51:17 +0100 (MET) 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 MAA00524; Sun, 19 Nov 2000 12:51:16 +0200 (EET) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id MAA08012; Sun, 19 Nov 2000 12:51:13 +0200 (EET) Message-ID: <3A17B08A.CF1D3933@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: farhan Cc: Gonzalo.Camarillo#b#Gonzalez/O=LMF/PRMD=Ericsson/ADMD=smtp/C=se@greymse1.lmf.ericsson.se, Henning Schulzrinne , Billy Biggs , SIP List Subject: Re: [SIP] a stupid question on 3way handshake References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A151FBB.57D381CD@ericsson.com> <003201c05125$b222f890$1200a8c0@bigboy> <20001118052434.A32315@div8.net> <000a01c0515a$a2777c60$1200a8c0@bigboy> <20001118070643.A32698@div8.net> <3A16B47E.819A7F53@cs.columbia.edu> <3A16C519.8A75A321@lmf.ericsson.se> <001101c0519e$bfb867f0$1200a8c0@bigboy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 12:50:50 +0200 Content-Transfer-Encoding: 7bit Hi, You were asking for the historical reason of having a 3-way handshake, and that is what I answered. Check page 6 of the first version of SIP and you will find the same explanation as I gave. http://www.cs.columbia.edu/sip/drafts/draft-ietf-mmusic-sip-00.ps More comments inline: farhan wrote: > > > A sends an INVITE to B and begin retransmitting it. After a while A > > gives up and stops retransmitting the INVITE. A thinks that there is no > > session established. > > > > At the same time (when A is giving up), B sends a 200 OK back. Since B > > observes that A has stopped retransmitting the INVITE the 200 OK in not > > retransmitted, B thinks that the session is established... > > imagine the samething happening on the ACK. Party B keeps sending 200 OK > until it times out and just then Party A responds back with an ACK and > considers that the session is established. No, that is not a solution we > need an infinite way handshake in such a case. Actually, if the network fails completely to deviler datagramas you definitively have a problem. However, a 3-way handshake makes B retransmit his 200 OK a number of times since the ACK has to been received. A big difference between the rest of the requests in SIP (that have a 2-way handshake) and INVITE (3-way handshake) is that the rest of the requests are usually retransmitted by the UA until the transaction is finished without the user stopping this process. For example, if a user hangs up (he is using a SIP phone) his UA will retransmit the BYE as many time as necessary until it gets a final response. However, the user can try to call someone and hang up before a final response arrives. This stops the retransmission process of the INVITE. But even if the 200 OK got lost, since the ACK will never arrive the callee will not believe that there is an established session. Best regards, Gonzalo > - farhan > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 14:39:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12164 for ; Sun, 19 Nov 2000 14:39:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB2B7443B8; Sun, 19 Nov 2000 13:39:08 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id C87C3443B7 for ; Sun, 19 Nov 2000 13:38:08 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Sun Nov 19 14:36:27 EST 2000 Received: by lists.bell-labs.com (Postfix) id 29F1644380; Sun, 19 Nov 2000 14:23:18 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id CEFD24437D for ; Sun, 19 Nov 2000 14:23:17 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA25264; Sun, 19 Nov 2000 13:23:15 -0600 Cc: "'farhan'" , Billy Biggs , SIP List Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA25222; Sun, 19 Nov 2000 13:23:12 -0600 Message-ID: <3A18289E.858ECBBC@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Original-CC: "'farhan'" , Billy Biggs , SIP List Subject: Re: [SIP] a stupid question on 3way handshake References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 13:23:10 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > Forking is fine for non-invite requests. It will result in reception of a > single response (which is, IMHO, a very nice property), which is the best > amongst all those received. Forking of non-INVITEs is therefore useful for > requests where it isn't important to know how many places received the > request; simply knowing the best response is adequate. [...] Except when multiple downstream UASes return a "best" response to a forked non-INVITE request. A while ago, we had a similar dialog regarding the forking of a non-INVITE request like OPTIONS. A forking proxy would send the initial OPTIONS to several branches downstream; suppose 2 branches returned a 200 OK. Then the proxy would send the first 200 OK received up- stream; absord the second 200 OK and send CANCEL on the remaining branches. Or the proxy could simply send multiple 200 OKs upstream and hope the UAC can sort them out and pick the "best". From a proxy's point of view, what exactly to do when multiple downstream UASes return a "best" response should be codified, IMHO. Otherwise, we could run into scenarios where on certain requests the proxy ONLY sends one "best" response upstream and in other cases it must send all "best" responses received upstream and leave the arbitration to the UAC. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 15:18:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12352 for ; Sun, 19 Nov 2000 15:18:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D738A443BE; Sun, 19 Nov 2000 14:18:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id D79A4443B7 for ; Sun, 19 Nov 2000 14:17:07 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sun, 19 Nov 2000 14:16:30 -0600 (CST) From: Billy Biggs To: Vijay Gurbani Cc: Jonathan Rosenberg , farhan , Billy Biggs , SIP List Subject: Re: [SIP] a stupid question on 3way handshake Message-ID: <20001119141630.A8427@div8.net> References: <3A18289E.858ECBBC@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A18289E.858ECBBC@lucent.com>; from vkg@lucent.com on Sun, Nov 19, 2000 at 01:23:10PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 14:16:30 -0600 Vijay Gurbani (vkg@lucent.com): > Jonathan Rosenberg wrote: > [...] > > Forking is fine for non-invite requests. It will result in reception > > of a single response (which is, IMHO, a very nice property), which > > is the best amongst all those received. Forking of non-INVITEs is > > therefore useful for requests where it isn't important to know how > > many places received the request; simply knowing the best response > > is adequate. > [...] > > Except when multiple downstream UASes return a "best" response to a > forked non-INVITE request. A while ago, we had a similar dialog > regarding the forking of a non-INVITE request like OPTIONS. A forking > proxy would send the initial OPTIONS to several branches downstream; > suppose 2 branches returned a 200 OK. Then the proxy would send the > first 200 OK received up- stream; absord the second 200 OK and send > CANCEL on the remaining branches. Or the proxy could simply send > multiple 200 OKs upstream and hope the UAC can sort them out and pick > the "best". The behavior is the same as for INVITE requests. If you receive multiple 200 OK responses, you MUST forward them up. That has been the consensus from everyone I've ever spoken with. However, since these responses are 'unreliable', dropping them is simply a simulation of bad network conditions, but I wouldn't recommend it. I was pretty sure this is spelled out in 2543, but I can't find an appropriate quote. Maybe it should be better spelled out. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 16:15:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12807 for ; Sun, 19 Nov 2000 16:15:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BFB5443BD; Sun, 19 Nov 2000 15:15:08 -0500 (EST) 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 9B1DA443B7 for ; Sun, 19 Nov 2000 15:14:07 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Sun Nov 19 16:12:17 EST 2000 Received: by lists.bell-labs.com (Postfix) id B3DD444380; Sun, 19 Nov 2000 15:59:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 674AE4437D for ; Sun, 19 Nov 2000 15:59:07 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA07942; Sun, 19 Nov 2000 14:59:04 -0600 Cc: Jonathan Rosenberg , SIP List Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA07930; Sun, 19 Nov 2000 14:59:02 -0600 Message-ID: <3A183F14.EBAB35EE@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Original-CC: Jonathan Rosenberg , SIP List Subject: Re: [SIP] a stupid question on 3way handshake References: <3A18289E.858ECBBC@lucent.com> <20001119141630.A8427@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 14:59:00 -0600 Content-Transfer-Encoding: 7bit Billy Biggs wrote: [...] > > Except when multiple downstream UASes return a "best" response to a > > forked non-INVITE request. A while ago, we had a similar dialog > > regarding the forking of a non-INVITE request like OPTIONS. A forking > > proxy would send the initial OPTIONS to several branches downstream; > > suppose 2 branches returned a 200 OK. Then the proxy would send the > > first 200 OK received up- stream; absord the second 200 OK and send > > CANCEL on the remaining branches. Or the proxy could simply send > > multiple 200 OKs upstream and hope the UAC can sort them out and pick > > the "best". > > The behavior is the same as for INVITE requests. If you receive > multiple 200 OK responses, you MUST forward them up. That has been the > consensus from everyone I've ever spoken with. Hmmm, let's see...the RFC does indicate that a forking proxy MAY terminate pending INVITE requests on other branches when it gets a 200 OK for at least one branch. Following this logic, it proxies the 200 OK it got _first_ up- stream and sends a CANCEL on all other branches. Say it gets another 200 OK (INVITE) after it has send a CANCEL; the proxy can rest assured that the CANCEL and the 200 OK (INVITE) "crossed each other on the wire." Thus it can locally ACK the 200 OK (INVITE) and then send a BYE on that branch. So, what I was trying to get at is that a proxy may exhibit the behavior I describe above and only send the first 200 OK upstream; further 200 OK (INVITE) maybe processed locally. Certainly this is not be true for all requests. It could very well be that forking proxies MUST send all 2xx responses to non-INVITE forked requests upstream as soon as they get it. For INVITE requests, they may exhibit the behavior described above. We should simply state that in the RFC so there are no ambiguities. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 16:43:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13043 for ; Sun, 19 Nov 2000 16:43:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5B2E443C6; Sun, 19 Nov 2000 15:43:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 2C061443C5 for ; Sun, 19 Nov 2000 15:42:29 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sun, 19 Nov 2000 15:42:19 -0600 (CST) From: Billy Biggs To: Vijay Gurbani Cc: Billy Biggs , Jonathan Rosenberg , SIP List Subject: Re: [SIP] a stupid question on 3way handshake Message-ID: <20001119154219.A8528@div8.net> References: <3A18289E.858ECBBC@lucent.com> <20001119141630.A8427@div8.net> <3A183F14.EBAB35EE@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A183F14.EBAB35EE@lucent.com>; from vkg@lucent.com on Sun, Nov 19, 2000 at 02:59:00PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 15:42:19 -0600 Vijay Gurbani (vkg@lucent.com): > > The behavior is the same as for INVITE requests. If you receive > > multiple 200 OK responses, you MUST forward them up. That has > > been the consensus from everyone I've ever spoken with. > > Hmmm, let's see...the RFC does indicate that a forking proxy MAY > terminate pending INVITE requests on other branches when it gets a 200 > OK for at least one branch. Following this logic, it proxies the 200 > OK it got _first_ up- stream and sends a CANCEL on all other branches. > Say it gets another 200 OK (INVITE) after it has send a CANCEL; the > proxy can rest assured that the CANCEL and the 200 OK (INVITE) > "crossed each other on the wire." Thus it can locally ACK the 200 OK > (INVITE) and then send a BYE on that branch. Sorry, but that would be really really evil. From RFC2543, 12.4: 2xx: The proxy MUST forward the response upstream towards the client, without sending an ACK downstream. After receiving a 2xx, the server MAY terminate all other pending requests by sending a CANCEL request and closing the TCP connection, if applicable. It's up to the client to BYE any additional calls -if it wants to-, not the proxy. It's perfectly acceptable to make one call and have two seperate locations pick up! The text reads that the proxy MUST not ACK the response locally to protect the UA. That is for any 2xx responses received. There might be reasons why the proxy would choose not to cancel the other branches (if there are no other branches? if the other branch is a call logger? who knows), and I think that is why the MAY is there. This behavior is the same for non-INVITE requests. I guess it could be stated more explicitly though. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 17:06:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13211 for ; Sun, 19 Nov 2000 17:06:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 156B5443C5; Sun, 19 Nov 2000 16:06:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8CD03443B7 for ; Sun, 19 Nov 2000 16:05:57 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA00820; Sun, 19 Nov 2000 17:08:08 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2ZG5C>; Sun, 19 Nov 2000 17:04:02 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , Vijay Gurbani Cc: Jonathan Rosenberg , SIP List Subject: RE: [SIP] a stupid question on 3way handshake MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 17:04:02 -0500 > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Sunday, November 19, 2000 4:42 PM > To: Vijay Gurbani > Cc: Billy Biggs; Jonathan Rosenberg; SIP List > Subject: Re: [SIP] a stupid question on 3way handshake > > > Vijay Gurbani (vkg@lucent.com): > > > > The behavior is the same as for INVITE requests. If you receive > > > multiple 200 OK responses, you MUST forward them up. That has > > > been the consensus from everyone I've ever spoken with. > > > > Hmmm, let's see...the RFC does indicate that a forking proxy MAY > > terminate pending INVITE requests on other branches when it > gets a 200 > > OK for at least one branch. Following this logic, it > proxies the 200 > > OK it got _first_ up- stream and sends a CANCEL on all > other branches. > > Say it gets another 200 OK (INVITE) after it has send a CANCEL; the > > proxy can rest assured that the CANCEL and the 200 OK (INVITE) > > "crossed each other on the wire." Thus it can locally ACK > the 200 OK > > (INVITE) and then send a BYE on that branch. > > Sorry, but that would be really really evil. Well, its not evil, but its not correct. Proxies don't initiate requests on their own, excepting the "special" ones of BYE and ACK (and for ACK, its only for non-200 responses. Proxies don't ACK 200 responses, only the UA does). > The text reads that the proxy MUST not ACK the response locally to > protect the UA. That is for any 2xx responses received. > There might be > reasons why the proxy would choose not to cancel the other > branches (if > there are no other branches? if the other branch is a call > logger? who > knows), and I think that is why the MAY is there. Yes. In fact, some time back, one of the request-disposition parameters in the caller preferences specification was something like "don't cancel". The point is that this is good for requests where you want to reach everyone, rather than just the first person to answer. > > This behavior is the same for non-INVITE requests. I guess it could > be stated more explicitly though. I agree that forking behavior for non-INVITE is not well specified enough. In fact, you previously write: > > Except when multiple downstream UASes return a "best" response to a > > forked non-INVITE request. A while ago, we had a similar dialog > > regarding the forking of a non-INVITE request like OPTIONS. > A forking > > proxy would send the initial OPTIONS to several branches downstream; > > suppose 2 branches returned a 200 OK. Then the proxy would send the > > first 200 OK received up- stream; absord the second 200 OK and send > > CANCEL on the remaining branches. Or the proxy could simply send > > multiple 200 OKs upstream and hope the UAC can sort them > out and pick > > the "best". > > The behavior is the same as for INVITE requests. If you receive > multiple 200 OK responses, you MUST forward them up. That > has been the > consensus from everyone I've ever spoken with. I'm sorry, that is not correct. A proxy cannot forward multiple non-INVITE responses upstream. A proxy cannot forward multiple non-INVITE responses upstream. Just to be sure: A proxy cannot forward multiple non-INVITE responses upstream. I'll put a FAQ entry in there too. It just doesn't work, plain and simple. The reliability mechanism as defined just doesn't work for multiple responses, and there is no way to fix it without pretty much adding in an ACK for non-INVITE requests. Billy also writes: > > [...] Forking of non-INVITEs is therefore useful for > requests where it > > isn't important to know how many places received the request; simply > > knowing the best response is adequate. [...] > > > > I would argue that SUBSCRIBE meets this criteria as well. The caller > > really doesn't care who many servers are going to be handling the > > subscription. So long as some server accepts it, and generates > > notifications for it, thats all that matters. > > It matters when trying to unsubscribe. To be intelligence- > at-the-edges correct, an unsubscribe should be sent within > the call-leg > created by the original SUBSCRIBE. However, to be forking-safe, the > unsubscribe should be sent to the orignal address which was subscribed > to, without a tag. Actually, I thought about this some more, and am not so sure that forking of SUBCSRIBE is such a great idea. THe problem is not just unsubscribes, but refreshes. One of the subscribe responses will come back, and it will likely be record-routed. As a result, subsequent subscribes will go to just the one server whose 200 response was forwarded upstream. Now, thats OK, but only if the multiple servers are all *equal*, that is, each is providing notifications for exactly the same set of devices for a particular presentity. So, to modify my description somewhat, "forking of non-INVITE requests works well when the client doesn't care from whom the response comes, and when the services provided by each of the servers that receives the request is identical." -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 17:29:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13294 for ; Sun, 19 Nov 2000 17:29:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9780443CE; Sun, 19 Nov 2000 16:29:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 103D4443CA for ; Sun, 19 Nov 2000 16:28:12 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sun, 19 Nov 2000 16:28:03 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Vijay Gurbani , SIP List Subject: Re: [SIP] a stupid question on 3way handshake Message-ID: <20001119162803.A8601@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Sun, Nov 19, 2000 at 05:04:02PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 16:28:03 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > [...] Proxies don't initiate requests on their own, excepting the > "special" ones of BYE and ACK (and for ACK, its only for non-200 > responses. [...] When would a proxy ever send a BYE? > A proxy cannot forward multiple non-INVITE responses upstream. I'm ok with this as long as it's clearly specified. > Actually, I thought about this some more, and am not so sure that > forking of SUBCSRIBE is such a great idea. THe problem is not just > unsubscribes, but refreshes. One of the subscribe responses will come > back, and it will likely be record-routed. As a result, subsequent > subscribes will go to just the one server whose 200 response was > forwarded upstream. Now, thats OK, but only if the multiple servers > are all *equal*, that is, each is providing notifications for exactly > the same set of devices for a particular presentity. Similarily, if I get a NOTIFY and I don't recognize the tags, I can't accept it and then unsubscribe since I don't have the route information (nor do I have a Contact address, since NOTIFY can't have a Contact. ??) The only sane thing to do is return a 481 and have that cancel the subscription. It would be wrong to ask that proxies not fork SUBSCRIBEs, or to suggest that SUBSCRIBE should always put in some 'don't-fork' caller preferences parameter. Forking of SUBSCRIBEs is useful. For example, subscribing to my voicemail status without using caller-preferences: the SUBSCRIBE forks to all my phones and my voicemail, and hopefully only the voicemail will accept it. Aside: Yet another reason you shouldn't always use the same local tag: You send a SUBSCRIBE and it comes back to yourself. ;-) Please take this error-prone suggestion out of bis. So, I guess we could suggest that when designing a SUBSCRIBE/NOTIFY system, make sure that the URIs used don't fork to multiple subscription handlers which handle the same event? -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 19:30:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13839 for ; Sun, 19 Nov 2000 19:30:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BA62443AE; Sun, 19 Nov 2000 18:30:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id ED66C443A8 for ; Sun, 19 Nov 2000 18:29:11 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Sun, 19 Nov 2000 16:28:57 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: SIP List MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Record-Route consensus Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 16:28:48 -0800 Was there any consensus reached on Record-Route changes? It would be nice to get this one nailed down. Problems to be solved: - handling of non-SIP Request-URI's properly. - request transaction identification in proxies for reverse direction (I forget the specifics) - proxy doesn't see any inserted record-route headers in reverse direction (eg loss of state or address info) - detecting new behaviour in Record-Route response. I think the first three can be solved by the UAS only replacing the user@host:port sections by the From/Contact in the reverse Route. The first also requires a new Record-Route header to store the maddr. This is used in preference to the maddr which might also be placed in the header for backwards compat. Detecting the new behaviour in the UAS? Any ideas? Having the UAS add a Record-Route parameter or adding something to its COntact are both fairly kludgey but would suffice. Proxies who support the new behavior but don't detect this added parameter in the response know that they must store full state for the call. 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 Sun Nov 19 20:49:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14227 for ; Sun, 19 Nov 2000 20:49:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E613F443A8; Sun, 19 Nov 2000 19:49:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id E5E6C443A8 for ; Sun, 19 Nov 2000 19:48:42 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sun, 19 Nov 2000 19:48:26 -0600 (CST) From: Billy Biggs To: "Fairlie-Cuninghame, Robert" Cc: SIP List Subject: Re: [SIP] Record-Route consensus Message-ID: <20001119194826.A8743@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from rfairlie@nuera.com on Sun, Nov 19, 2000 at 04:28:48PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 19:48:26 -0600 Fairlie-Cuninghame, Robert (rfairlie@nuera.com): > Was there any consensus reached on Record-Route changes? It would be > nice to get this one nailed down. In my opinion, the consensus is that going through all the addresses in the Record-Route and changing them for the reverse direction is out. Proxies should insert an address that indicates to them enough state to perform their function, and the spec should probably give some examples. The only open issue is whether to allow non-SIP URIs in the Route. In order to support them, the suggestion is to define Record-Route parameters to indicate the IP address, port, and transport. I think this is dangerous because it won't work with outbound proxies. Does anyone feel strongly otherwise? See my post: http://lists.bell-labs.com/pipermail/sip/2000q4/004005.html And Sean Olson's post on other URI schemes: http://lists.bell-labs.com/pipermail/sip/2000q4/004037.html -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 19 22:22:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15689 for ; Sun, 19 Nov 2000 22:22:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 184E644368; Sun, 19 Nov 2000 21:22:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BCCCB44352 for ; Sun, 19 Nov 2000 21:21:08 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA01232 for ; Sun, 19 Nov 2000 22:23:26 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2ZG77>; Sun, 19 Nov 2000 22:19:20 -0500 Message-ID: From: Jonathan Rosenberg 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] New I-D on multiparty conferencing models Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 22:19:19 -0500 Folks, I submitted a draft last Friday on multiparty conferencing models. It shows how to do multiparty conferencing six different ways with baseline SIP. Until it appears, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-conferencing- models-00.txt 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 Mon Nov 20 01:12:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18863 for ; Mon, 20 Nov 2000 01:12:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EE6D44345; Mon, 20 Nov 2000 00:12:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by lists.bell-labs.com (Postfix) with ESMTP id C9DCD44352 for ; Sun, 19 Nov 2000 21:49:17 -0500 (EST) Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id JAA28558 for ; Mon, 20 Nov 2000 09:25:59 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA1747; Mon, 20 Nov 2000 09:09:58 +0530 Message-ID: <012501c051dc$7563bea0$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Rohan Mahy" , "Sean Olson" Cc: References: <4.1.20001116151548.00cc2850@imop.cisco.com> <4.1.20001117102008.00a85c50@imop.cisco.com> Subject: Re: [SIP] ID extension of REFER MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 19 Nov 2000 09:24:44 +0530 Content-Transfer-Encoding: 7bit Wouldn't simply forwarding the provisionals received allow the initiator of REFER know more about 'call progress' instead of translating them to a single 189 ? Are there any specific reasons against not doing so? Please elaborate. Venkatesh ----- Original Message ----- From: "Rohan Mahy" To: "Sean Olson" Cc: Sent: Friday, November 17, 2000 11:58 PM Subject: Re: [SIP] ID extension of REFER > At 02:02 AM 11/17/00 , Sean Olson wrote: > >Hello, > > > >I am a little confused about the purpose of this I-D. The first question > >that springs to mind is > >why you don't use "183" for this purpose? > > the semantics of 183 already means something different, and i did not think > I could overload those semantics cleanly. > > >The second question is whether you > >intend the 189 to lead to different timing than any other provisional > >response? > > A sends REFER to B > B sends INVITE to C > > A would get 189s any time B got provisionals from C. > > If C just 200 OKs B's INVITE, no 189s are sent. > If C sends 180 or 183 and answers right away, A still gets a 189. If you > don't need the information you can ignore it. > > thanks, > -rohan > > >(In other words, if the 189 does NOT cause different timing, than the > >issue of a long > > period (> 37 seconds) between the INVITE and 200 OK is not really > >solved. I realize > > this should be a very rare case.) > > > >/sean > > > >Rohan Mahy wrote: > > > >> Hi, > >> > >> I just submitted an ID for an extension to the REFER method that I > >> discussed with Robert Sparks at Pittsburgh. Until it appears in the > >> archive it is available at: > >> > >> ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-189-00.txt > >> > >> > >> A SIP Extension: Informational Responses to the REFER method > >> > >> Abstract > >> > >> This document defines a SIP extension to the REFER method of the > >> SIP Call Control Framework. This extension provides for the > >> ability to convey information about the progress of the Referred > >> request when that request is in a provisional state for a long > >> period of time (many seconds or minutes). > >> > >> > >> Comments welcome. > >> > >> thanks, > >> -rohan > >> > >> > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 20 01:20: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 BAA19992 for ; Mon, 20 Nov 2000 01:20:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF6A244386; Mon, 20 Nov 2000 00:20:08 -0500 (EST) 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 2502944338 for ; Mon, 20 Nov 2000 00:19:03 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id XAA23407 for ; Sun, 19 Nov 2000 23:18:36 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id XAA00746 for ; Sun, 19 Nov 2000 23:18:33 -0700 (MST)] Received: from miel.mot.com (pc128130.miel.mot.com [217.1.128.130]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id LAA13647 for ; Mon, 20 Nov 2000 11:53:58 +0530 (IST) Message-ID: <3A190F53.EAAE60D9@miel.mot.com> From: sreenivasa reddy D X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] spaces in SIP-URL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 11:47:32 +0000 Content-Transfer-Encoding: 7bit Hi, In SIP-URL where spaces and line breaks are allowed. i have seen grammar in sip-rfc2543.what i feel is in between "sip:" and user, user and password, password and host. host and port port and url-parameter, url parameters url-parameter and header headers. Spaces are allowed.and where ever spaces are allowed line breaks are also allowed. i want to know whether iam right or not.if iam wrong please tell me correct one. thanks, regards Sreenivasa Reddy.D _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 01:49: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 BAA24031 for ; Mon, 20 Nov 2000 01:49:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9A9F944395; Mon, 20 Nov 2000 00:49:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 7AF5044338 for ; Mon, 20 Nov 2000 00:48:55 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eAK6nf212815; Mon, 20 Nov 2000 12:20:01 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eAK6vFP20397; Mon, 20 Nov 2000 12:27:20 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525699D.0025A539 ; Mon, 20 Nov 2000 12:21:11 +0530 X-Lotus-FromDomain: HSSBLR From: airoy@hss.hns.com To: sreenivasa reddy D Cc: sip Message-ID: <6525699D.0025A4EE.00@sampark.hss.hns.com> Subject: Re: [SIP] spaces in SIP-URL Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 12:21:09 +0530 you are pretty much on track....some additions are between the user and the "@" between the "@" and the host between host and " : " between ":" and port between port and ";" between ";" and url and so on...you have left out separators. You can have spaces or line folds between any 2 tokens , separators or otherwise. -ashok ------------ ashok i roy @hughes software systems ------------- sreenivasa reddy D on 11/20/2000 05:17:32 PM To: sip cc: (bcc: Ashok I Roy/HSSBLR) Subject: [SIP] spaces in SIP-URL Hi, In SIP-URL where spaces and line breaks are allowed. i have seen grammar in sip-rfc2543.what i feel is in between "sip:" and user, user and password, password and host. host and port port and url-parameter, url parameters url-parameter and header headers. Spaces are allowed.and where ever spaces are allowed line breaks are also allowed. i want to know whether iam right or not.if iam wrong please tell me correct one. thanks, regards Sreenivasa Reddy.D _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 20 04:49: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 EAA03386 for ; Mon, 20 Nov 2000 04:49:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F3D944344; Mon, 20 Nov 2000 03:49:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 1021744338 for ; Mon, 20 Nov 2000 03:48:30 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 20 Nov 2000 09:48:19 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA18040; Mon, 20 Nov 2000 10:46:37 +0100 (BST) From: "Jo Hornsby" To: "Billy Biggs" , "Fairlie-Cuninghame, Robert" Cc: "SIP List" Subject: RE: [SIP] Record-Route consensus Message-ID: <002001c052d6$c6b259b0$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 Importance: Normal In-Reply-To: <20001119194826.A8743@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 09:46:37 -0000 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > Fairlie-Cuninghame, Robert (rfairlie@nuera.com): > > > Was there any consensus reached on Record-Route changes? It would be > > nice to get this one nailed down. > > In my opinion, the consensus is that going through all the addresses > in the Record-Route and changing them for the reverse direction is out. > Proxies should insert an address that indicates to them enough state to > perform their function, and the spec should probably give some examples. > > The only open issue is whether to allow non-SIP URIs in the Route. In > order to support them, the suggestion is to define Record-Route > parameters to indicate the IP address, port, and transport. I think > this is dangerous because it won't work with outbound proxies. I'd like to take this oppurtunity &:) to point out that the solution I proposed -- just inserting the SIP URL of the proxy, and embedding the Request-URI as a parameter thereof -- handles non-SIP URIs. I did go a step further, and suggest that called UAs did extra mangling in the reverse direction, in that they insert the Contact address of the caller UA as another parameter; however, it doesn't so matter whether this is done or not, since it would only come into play if the Route broke somehow. So, for example, say I'm a proxy on the machine sip0.example.com, listening on port 6000. I receive a request: INVITE tel:999 SIP/2.0 ... I proxy on: INVITE sip:999@emergency.sip-gateways.com SIP/2.0 ... Record-Route: ... Hopefully, it's now evident that in either direction, I am going to be totally routeable (as long as sip0.example.com is globally routeable), so as long as both caller and called UA copy all parameters. Unfortunately, we do lose the notion that the Request-URI contains, somehow, the ultimate destination, but it would be possible to perhaps have a BCP along the lines of called UAs inserting another parameter indicating the Contact/From (I guess it could literally be done as a header parameter). I did originally propose renaming uri to original-uri, and making uri the Contact/From, yada yada, but it does seem unecessarily painful to me now. 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 Mon Nov 20 05:49: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 FAA03758 for ; Mon, 20 Nov 2000 05:49:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB0D84438C; Mon, 20 Nov 2000 04:49:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 66C1B44338 for ; Mon, 20 Nov 2000 04:48:13 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 20 Nov 2000 10:48:06 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA06209; Mon, 20 Nov 2000 11:46:34 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , "'Billy Biggs'" , "Vijay Gurbani" Cc: "SIP List" Subject: RE: [SIP] a stupid question on 3way handshake Message-ID: <002501c052df$2701fc00$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 Importance: Normal In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 10:46:35 -0000 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Well, its not evil, but its not correct. Proxies don't initiate > requests on their own, excepting the "special" ones of BYE Do you mean CANCEL? > So, to modify my description somewhat, "forking of non-INVITE > requests works well when the client doesn't care from whom the > response comes, and when the services provided by each of the > servers that receives the request is identical." I'm playing Devil's Advocate here, but isn't that better achieved by SRV? I like forking -- it's very powerful; however, I might be inclined to suggest that we warn in bis that proxies shouldn't be too keen to fork on non-INVITE requests, since in a number of cases, it's probably not going to be so helpful. 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 Nov 20 05:50:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03784 for ; Mon, 20 Nov 2000 05:50:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7AE2C443BC; Mon, 20 Nov 2000 04:50:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from fepB.post.tele.dk (fepB.post.tele.dk [195.41.46.145]) by lists.bell-labs.com (Postfix) with ESMTP id C393444338 for ; Mon, 20 Nov 2000 04:49:22 -0500 (EST) Received: from dynamicsoft.com ([195.249.119.106]) by fepB.post.tele.dk (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001120104914.REGK2411.fepB.post.tele.dk@dynamicsoft.com>; Mon, 20 Nov 2000 11:49:14 +0100 Message-ID: <3A190144.4942799B@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: airoy@hss.hns.com Cc: sreenivasa reddy D , sip Subject: Re: [SIP] spaces in SIP-URL References: <6525699D.0025A4EE.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 11:47:32 +0100 Content-Transfer-Encoding: 7bit airoy@hss.hns.com wrote: > > you are pretty much on track....some additions are > between the user and the "@" > between the "@" and the host > between host and " : " > between ":" and port > between port and ";" > between ";" and url > and so on...you have left out separators. You can have spaces or line > folds between any 2 tokens , separators or otherwise. Why do you think spaces here are legal? As far as I can tell rfc 2396, "Uniform Resource Identifiers (URI): Generic Syntax" seems to clearly spaces in URIs altogether. The comments on "implied *LWS" in appendix B of rfc 2543 doesn't change this. Anders _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 06:26:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05603 for ; Mon, 20 Nov 2000 06:26:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D800F443AC; Mon, 20 Nov 2000 05:26:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from fepZ.post.tele.dk (fepz.post.tele.dk [195.41.46.133]) by lists.bell-labs.com (Postfix) with ESMTP id 5879D44372 for ; Mon, 20 Nov 2000 05:25:47 -0500 (EST) Received: from dynamicsoft.com ([195.249.119.98]) by fepZ.post.tele.dk (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001120112539.QYZQ4174.fepZ.post.tele.dk@dynamicsoft.com>; Mon, 20 Nov 2000 12:25:39 +0100 Message-ID: <3A1909CD.D43B28C9@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Jonathan Rosenberg , "'Billy Biggs'" , Vijay Gurbani , SIP List Subject: Re: [SIP] a stupid question on 3way handshake References: <002501c052df$2701fc00$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: Mon, 20 Nov 2000 12:23:57 +0100 Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > I like forking -- it's very powerful; however, I might be > inclined to suggest that we warn in bis that proxies > shouldn't be too keen to fork on non-INVITE requests, since > in a number of cases, it's probably not going to be so > helpful. Hmmm. If it's OK to register multiple SIP addresses at a registrar and have a proxy fork INVITEs to those addresses it pretty much follows that OPTIONS, SUBSCRIBE, and other requests must also be allowed to fork in order to be useful. Anders _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 06:29:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05646 for ; Mon, 20 Nov 2000 06:29:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01102443CF; Mon, 20 Nov 2000 05:29:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id F01B5443CF for ; Mon, 20 Nov 2000 05:28:07 -0500 (EST) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eAKBS0t15827; Mon, 20 Nov 2000 12:28:00 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id eAKBRxv17580; Mon, 20 Nov 2000 12:27:59 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id MAA19366; Mon, 20 Nov 2000 12:27:58 +0100 (MET) Message-ID: <3A190AB8.F75B4A7B@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Cc: Billy Biggs Subject: Re: [SIP] Record-Route consensus References: <8vabbr$a6t$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 12:27:52 +0100 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > Fairlie-Cuninghame, Robert (rfairlie@nuera.com): > > > Was there any consensus reached on Record-Route changes? It would be > > nice to get this one nailed down. > > In my opinion, the consensus is that going through all the addresses > in the Record-Route and changing them for the reverse direction is out. > Proxies should insert an address that indicates to them enough state to > perform their function, and the spec should probably give some examples. > > The only open issue is whether to allow non-SIP URIs in the Route. In > order to support them, the suggestion is to define Record-Route > parameters to indicate the IP address, port, and transport. I think > this is dangerous because it won't work with outbound proxies. > Hi, I don't I understand why this will not work with outbound proxies. If you have a firewall that can handle SIP that firewall will need to work as a SIP proxy and thereby add itself to the ROUTE chain. That 'proxy' also needs to be addressable from outside the firewall how will you otherwise be able to call someone behind the firewall ? /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 Nov 20 06:40: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 GAA05891 for ; Mon, 20 Nov 2000 06:40:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 763FF443D4; Mon, 20 Nov 2000 05:40:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 6388B44338 for ; Mon, 20 Nov 2000 05:39:45 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 20 Nov 2000 11:39:38 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA27160; Mon, 20 Nov 2000 12:38:06 +0100 (BST) From: "Jo Hornsby" To: "Anders Kristensen" Cc: "Jonathan Rosenberg" , "'Billy Biggs'" , "Vijay Gurbani" , "SIP List" Subject: RE: [SIP] a stupid question on 3way handshake Message-ID: <002b01c052e6$59258240$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 Importance: Normal In-Reply-To: <3A1909CD.D43B28C9@dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 11:38:05 -0000 Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > > > I like forking -- it's very powerful; however, I might be > > inclined to suggest that we warn in bis that proxies > > shouldn't be too keen to fork on non-INVITE requests, since > > in a number of cases, it's probably not going to be so > > helpful. > > Hmmm. If it's OK to register multiple SIP addresses at a registrar and > have a proxy fork INVITEs to those addresses it pretty much follows that > OPTIONS, SUBSCRIBE, and other requests must also be allowed to fork in > order to be useful. I think it's OPTIONS that bothers me the most. You try to gather some information on the UA you're about to call with an OPTIONS, and it forks. The result of the OPTIONS could be completely useless, because it may well not be from the UA that you would actually have ended up talking to if you'd done an INVITE instead. I don't know -- maybe it's a silly point, but forking just seems to slightly spoil OPTIONS. Okay, so maybe Billy's suggestion was better: suggest sequential forking as nominal behaviour for non-INVITE. This doesn't help at all with the OPTIONs case, but it's probably better for things like BYE, for instance. - 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 Nov 20 08:33:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08974 for ; Mon, 20 Nov 2000 08:33:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1269B443CA; Mon, 20 Nov 2000 07:33:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f113.pav1.hotmail.com [64.4.31.113]) by lists.bell-labs.com (Postfix) with ESMTP id 95F354438C for ; Mon, 20 Nov 2000 04:01:37 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 20 Nov 2000 02:01:29 -0800 Received: from 195.48.203.130 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 20 Nov 2000 10:01:29 GMT X-Originating-IP: [195.48.203.130] From: "Lewis Gibbon" To: SIP@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2000 10:01:29.0962 (UTC) FILETIME=[DA8F6CA0:01C052D8] Subject: [SIP] Open Source? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 10:01:29 GMT Dear All, Are there any open source SIP stacks for the Windows OS? Regards, Lewis. _________________________________________________________________________ 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 Mon Nov 20 08:34: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 IAA09019 for ; Mon, 20 Nov 2000 08:34:33 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 02D3D443DB; Mon, 20 Nov 2000 07:33:22 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 26DEE44372 for ; Mon, 20 Nov 2000 05:17:55 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05328; Mon, 20 Nov 2000 06:17:40 -0500 (EST) Message-Id: <200011201117.GAA05328@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-service-examples-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 06:17:40 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Telephony Service Examples Author(s) : A. Johnston, R. Sparks, C. Cunningham, S. Donovan, K. Summers Filename : draft-ietf-sip-service-examples-00.txt Pages : 90 Date : 17-Nov-00 This document gives examples of SIP (Session Initiation Protocol) telephony services. This covers most features offered in so-called Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP User Agents, although some require the assistance of a SIP Proxy. Some require some extensions to SIP including third party call control (3pcc) extensions such as the REFER method. These features are not intented to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP Telephones in a business environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-service-examples-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-service-examples-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-service-examples-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001117145852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-service-examples-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-service-examples-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001117145852.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 09:24: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 JAA10776 for ; Mon, 20 Nov 2000 09:24:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A3286443B2; Mon, 20 Nov 2000 08:24:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id F23E144354 for ; Mon, 20 Nov 2000 08:23:32 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA25599; Mon, 20 Nov 2000 09:22:40 -0500 (EST) Message-ID: <3A1933B0.16C82584@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: airoy@hss.hns.com, sreenivasa reddy D , sip Subject: Re: [SIP] spaces in SIP-URL References: <6525699D.0025A4EE.00@sampark.hss.hns.com> <3A190144.4942799B@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 09:22:40 -0500 Content-Transfer-Encoding: 7bit URLs, SIP or otherwise, cannot have unescaped spaces. Never have, never will. Anders Kristensen wrote: > > airoy@hss.hns.com wrote: > > > > you are pretty much on track....some additions are > > between the user and the "@" > > between the "@" and the host > > between host and " : " > > between ":" and port > > between port and ";" > > between ";" and url > > and so on...you have left out separators. You can have spaces or line > > folds between any 2 tokens , separators or otherwise. > > Why do you think spaces here are legal? As far as I can tell rfc 2396, > "Uniform Resource Identifiers (URI): Generic Syntax" seems to clearly > spaces in URIs altogether. The comments on "implied *LWS" in appendix B > of rfc 2543 doesn't change this. > > Anders > -- 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 Nov 20 10:16:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12379 for ; Mon, 20 Nov 2000 10:16:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2532344354; Mon, 20 Nov 2000 09:16:09 -0500 (EST) 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 F1F0144349 for ; Mon, 20 Nov 2000 09:15:22 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 20 Nov 2000 15:15:13 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id PAA08841; Mon, 20 Nov 2000 15:15:12 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025699D.0053BFC1 ; Mon, 20 Nov 2000 15:14:45 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Stuart Wray" To: sip@lists.bell-labs.com Message-ID: <8025699D.0053BC19.00@marconicomms.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] URL comparison Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 15:14:34 +0000 Henning Schulzrinne suggested that I submit the following questions about URL comparison to the SIP list. On page 21 of rfc2543bis02 , it says (call this clause A) "user, password, host, port and any url-parameter parameters of the URI must match. If a component is omitted, it matches based on its default value." So far, this is clear, but the paragraph goes on to say that (call this clause B) "Components not found in both URLs being compared are ignored" Now consider these two URLs: sip:juser@example.com:6666 sip:juser@example.com Clause A means that these URLs compare as unequal, but clause B means that they compare as equal. Should clause B actually start with the word "other"? (clause B') "Other components not found in both URLs being compared are ignored" (If so, is this actually the correct judgement? I would have thought that a URL should not compare equal to a URL with an extra component. Why is it useful for them to compare equal?) And now another separate point: the text on page 21 goes on to say: "Note that the two URLs example.com and example.com:5060, while considered equal, may not lead to the same server, as the former causes a DNS SRV lookup, while the latter only uses the A record". However, this is not true --- on page 12 it says: "3. The Request-URI is examined. If it contains an explicit port number other than 5060, the next two steps are skipped". The A record is only used if there is a port number other than 5060 ---- so example.com and example.com:5060 both use the SRV record. (Of course this may result in different machines actually being contacted, but that's a different matter entirely, not to do with A records). Stuart Wray _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 10:18: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 KAA12422 for ; Mon, 20 Nov 2000 10:18:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E10844371; Mon, 20 Nov 2000 09:18:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id AC7B74436B for ; Mon, 20 Nov 2000 09:17:53 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for SIP@lists.bell-labs.com; Mon, 20 Nov 2000 09:17:46 -0600 (CST) From: Billy Biggs To: Bertil Engelholm Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] Record-Route consensus Message-ID: <20001120091746.A9602@div8.net> References: <8vabbr$a6t$1@lux2.datacom-lab.uab.ericsson.se> <3A190AB8.F75B4A7B@uab.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A190AB8.F75B4A7B@uab.ericsson.se>; from Bertil.Engelholm@uab.ericsson.se on Mon, Nov 20, 2000 at 12:27:52PM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 09:17:46 -0600 Bertil Engelholm (Bertil.Engelholm@uab.ericsson.se): > Billy Biggs wrote: > > > > The only open issue is whether to allow non-SIP URIs in the Route. > > In order to support them, the suggestion is to define Record-Route > > parameters to indicate the IP address, port, and transport. I > > think this is dangerous because it won't work with outbound > > proxies. > > I don't I understand why this will not work with outbound proxies. If > you have a firewall that can handle SIP that firewall will need to > work as a SIP proxy and thereby add itself to the ROUTE chain. That > 'proxy' also needs to be addressable from outside the firewall how > will you otherwise be able to call someone behind the firewall ? Proxies don't need to add themselves to the Route. So, say I buy a SIP phone and I set its outbound proxy to be some SIP proxy on the Internet which doesn't add itself to the route, and then some bozo puts as the first Record-Route: R-R: ;sendto=12.43.52.23:5060;transport=udp What can I do? The phone has to send the request to its outbound proxy. You get the same problem if you configure a SIP proxy to forward all requests it gets to another proxy: you can't convey these parameters in the request-URI. This shows why its too brittle to allow non-SIP URIs in the Route, unless you force every proxy to know how to route based on tel: or http: URIs... ;-) -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 10:24: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 KAA12638 for ; Mon, 20 Nov 2000 10:24:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F00BF443E2; Mon, 20 Nov 2000 09:24:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 85CBA443E1 for ; Mon, 20 Nov 2000 09:23:13 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 09:23:01 -0600 (CST) From: Billy Biggs To: Jo Hornsby Cc: "Fairlie-Cuninghame, Robert" , SIP List Subject: Re: [SIP] Record-Route consensus Message-ID: <20001120092301.B9602@div8.net> References: <20001119194826.A8743@div8.net> <002001c052d6$c6b259b0$4e34c3c1@ubiquity.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <002001c052d6$c6b259b0$4e34c3c1@ubiquity.co.uk>; from jhornsby@ubiquity.net on Mon, Nov 20, 2000 at 09:46:37AM -0000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 09:23:01 -0600 Jo Hornsby (jhornsby@ubiquity.net): > > The only open issue is whether to allow non-SIP URIs in the Route. > > In order to support them, the suggestion is to define Record-Route > > parameters to indicate the IP address, port, and transport. I > > think this is dangerous because it won't work with outbound > > proxies. > > I'd like to take this oppurtunity &:) to point out that the solution I > proposed -- just inserting the SIP URL of the proxy, and embedding the > Request-URI as a parameter thereof -- handles non-SIP URIs. Right, but this is a special case of not allowing SIP URIs. If you're a proxy that needs (for its state information or whatever) to know the orignal request-URI it saw, then of course, throw it as a parameter. But many (most? if not all?) proxies won't need this state to perform their job. Please see my post on this: http://lists.bell-labs.com/pipermail/sip/2000q4/004005.html > I did go a step further, and suggest that called UAs did extra > mangling in the reverse direction, [...] In my opinion, this increases the complexity for little gain. Basically, you're just proposing that we don't allow non-SIP URIs in the Route, and I think this is completely reasonable. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 10:29: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 KAA12809 for ; Mon, 20 Nov 2000 10:29:49 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EC27443ED; Mon, 20 Nov 2000 09:26:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id CBFC2443EB for ; Mon, 20 Nov 2000 09:25:48 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 09:25:42 -0600 (CST) From: Billy Biggs To: Jo Hornsby Cc: SIP List Subject: Re: [SIP] a stupid question on 3way handshake Message-ID: <20001120092542.C9602@div8.net> References: <3A1909CD.D43B28C9@dynamicsoft.com> <002b01c052e6$59258240$4e34c3c1@ubiquity.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <002b01c052e6$59258240$4e34c3c1@ubiquity.co.uk>; from jhornsby@ubiquity.net on Mon, Nov 20, 2000 at 11:38:05AM -0000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 09:25:42 -0600 Jo Hornsby (jhornsby@ubiquity.net): > Okay, so maybe Billy's suggestion was better: suggest sequential > forking as nominal behaviour for non-INVITE. This doesn't help at all > with the OPTIONs case, but it's probably better for things like BYE, > for instance. That's funny, because it seems completely reasonable to me to parallel fork a BYE. You would get a BYE at a proxy when the stupid UA at the other end didn't put in a Contact. You want to shut down the call quickly, so you parallel fork to all registrations knowing that all but one will return a 481. So much for my suggestion. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 10:42: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 KAA13291 for ; Mon, 20 Nov 2000 10:42:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ABD1F443E9; Mon, 20 Nov 2000 09:42:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 5F1B0443E1 for ; Mon, 20 Nov 2000 09:41:40 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 20 Nov 2000 15:41:33 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA06861; Mon, 20 Nov 2000 16:40:02 +0100 (BST) From: "Jo Hornsby" To: "Billy Biggs" Cc: "Fairlie-Cuninghame, Robert" , "SIP List" Subject: RE: [SIP] Record-Route consensus Message-ID: <003201c05308$25ac3360$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 Importance: Normal In-Reply-To: <20001120092301.B9602@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 15:40:02 -0000 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > Jo Hornsby (jhornsby@ubiquity.net): > > > > The only open issue is whether to allow non-SIP URIs in the Route. > > > In order to support them, the suggestion is to define Record-Route > > > parameters to indicate the IP address, port, and transport. I > > > think this is dangerous because it won't work with outbound > > > proxies. > > > > I'd like to take this oppurtunity &:) to point out that the solution I > > proposed -- just inserting the SIP URL of the proxy, and embedding the > > Request-URI as a parameter thereof -- handles non-SIP URIs. > > Right, but this is a special case of not allowing SIP URIs. If you're > a proxy that needs (for its state information or whatever) to know the > orignal request-URI it saw, then of course, throw it as a parameter. > But many (most? if not all?) proxies won't need this state to perform > their job. Please see my post on this: > > http://lists.bell-labs.com/pipermail/sip/2000q4/004005.html Right. So we're saying remove the bit where the bis specifies that the Request-URI is copied into the Record-Route, and instead note that the proxy is free to put any SIP URL in (of course, it should be routable); and also remove the bit where the bis specifies the Route Request-URI mangling by the called UA. > > I did go a step further, and suggest that called UAs did extra > > mangling in the reverse direction, [...] > > In my opinion, this increases the complexity for little gain. I certainly wouldn't argue this point. It's just an option, if someone feels they really need it. > Basically, you're just proposing that we don't allow non-SIP URIs in > the Route, and I think this is completely reasonable. Agreed. After all, we already say that a proxy is not allowed to mandate TCP (via the transport parameter) in Record-Route; allowing non-SIP URIs, I would say, is orders of magnitude more painful. 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 Nov 20 10:57: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 KAA13723 for ; Mon, 20 Nov 2000 10:57:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F26FF443D7; Mon, 20 Nov 2000 09:57:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 20D9F44349 for ; Mon, 20 Nov 2000 09:56:10 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 09:55:59 -0600 (CST) From: Billy Biggs To: Jo Hornsby Cc: Sean Olson , "Fairlie-Cuninghame, Robert" , SIP List Subject: Re: [SIP] Record-Route consensus Message-ID: <20001120095559.A9722@div8.net> References: <20001120092301.B9602@div8.net> <003201c05308$25ac3360$4e34c3c1@ubiquity.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <003201c05308$25ac3360$4e34c3c1@ubiquity.co.uk>; from jhornsby@ubiquity.net on Mon, Nov 20, 2000 at 03:40:02PM -0000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 09:55:59 -0600 Jo Hornsby (jhornsby@ubiquity.net): > Right. So we're saying remove the bit where the bis specifies that > the Request-URI is copied into the Record-Route, and instead note that > the proxy is free to put any SIP URL in (of course, it should be > routable); and also remove the bit where the bis specifies the Route > Request-URI mangling by the called UA. Totally. It should put in some SIP URI that is routable in both directions. > > Basically, you're just proposing that we don't allow non-SIP URIs > > in the Route, and I think this is completely reasonable. > > Agreed. After all, we already say that a proxy is not allowed to > mandate TCP (via the transport parameter) in Record-Route; allowing > non-SIP URIs, I would say, is orders of magnitude more painful. Dude, you rock my world. Now, where's Sean Olson's argument? :) -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 12:35:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02964 for ; Mon, 20 Nov 2000 12:35:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF9634434B; Mon, 20 Nov 2000 11:35:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B215444349 for ; Mon, 20 Nov 2000 11:34:23 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA06127 for ; Mon, 20 Nov 2000 12:36:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 12:32:34 -0500 Message-ID: From: Jonathan Rosenberg To: Igor Slepchin , sip@lists.bell-labs.com Subject: RE: [SIP] draft-byerly-sip-radius-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 12:32:34 -0500 Absolutely correct. In fact, the only real difference between the chap based authentication and digest should be the formatting of the response value. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Igor Slepchin [mailto:ISlepchin@dynamicsoft.com] > Sent: Wednesday, November 15, 2000 8:58 PM > To: sip@lists.bell-labs.com > Subject: [SIP] draft-byerly-sip-radius-00.txt > > > Minor comment on draft-byerly-sip-radius-00.txt: the draft > seems to deviate > unnecessarily from the challenge and credentials syntax specified in > RFC2617, i.e., it uses semicolon to separate challenge/credentials > parameters instead of reusing comma-separation mandated by HTTP > Basic/Digest. I think consistency with HTTP should be > maintained wherever > possible. > > Thank you, > 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 Mon Nov 20 12:41: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 MAA04554 for ; Mon, 20 Nov 2000 12:41:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 55AC54436F; Mon, 20 Nov 2000 11:41:08 -0500 (EST) 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 811CB4436B for ; Mon, 20 Nov 2000 11:40:45 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA06850 for ; Mon, 20 Nov 2000 10:40:38 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA15646 for ; Mon, 20 Nov 2000 10:40:37 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 20 Nov 2000 11:40:37 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8691@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Subject: [SIP] SIP Registration minimal interval? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 11:40:36 -0600 Hi Is there any 'floor limitation' on the registration interval? I mean, let's say the registrar asks the client to register every 20 minutes. Can the client decide to register every 1 minute? If YES, do we have any way to prevent malicious or badly configured client from overloading the network? Thanks Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 12:46: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 MAA05796 for ; Mon, 20 Nov 2000 12:46:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 556A2443DE; Mon, 20 Nov 2000 11:46:08 -0500 (EST) 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 542A8443DA for ; Mon, 20 Nov 2000 11:45:04 -0500 (EST) 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 JAA21309; Mon, 20 Nov 2000 09:44:55 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAA85635; Mon, 20 Nov 2000 09:44:50 -0800 (PST) Message-Id: <4.1.20001120093503.00cdc5c0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: "Venkatesh Venkataramanan" , "Sean Olson" From: Rohan Mahy Subject: Re: [SIP] ID extension of REFER Cc: In-Reply-To: <012501c051dc$7563bea0$0c47a8c0@wipro.com> References: <4.1.20001116151548.00cc2850@imop.cisco.com> <4.1.20001117102008.00a85c50@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 09:38:33 -0800 I am open to this option. Realize however, that REFER summarizes final responses so summarizing provisionals is consistent with behavior that exists today; and that simply forwarding other provisionals overloads their semantics. thanks, -rohan At 07:54 PM 11/18/00 , Venkatesh Venkataramanan wrote: >Wouldn't simply forwarding the provisionals received allow the initiator of >REFER know more about 'call progress' instead of translating them to a >single 189 ? Are there any specific reasons against not doing so? Please >elaborate. > >Venkatesh >----- Original Message ----- >From: "Rohan Mahy" >To: "Sean Olson" >Cc: >Sent: Friday, November 17, 2000 11:58 PM >Subject: Re: [SIP] ID extension of REFER > > >> At 02:02 AM 11/17/00 , Sean Olson wrote: >> >Hello, >> > >> >I am a little confused about the purpose of this I-D. The first question >> >that springs to mind is >> >why you don't use "183" for this purpose? >> >> the semantics of 183 already means something different, and i did not >think >> I could overload those semantics cleanly. >> >> >The second question is whether you >> >intend the 189 to lead to different timing than any other provisional >> >response? >> >> A sends REFER to B >> B sends INVITE to C >> >> A would get 189s any time B got provisionals from C. >> >> If C just 200 OKs B's INVITE, no 189s are sent. >> If C sends 180 or 183 and answers right away, A still gets a 189. If you >> don't need the information you can ignore it. >> >> thanks, >> -rohan >> >> >(In other words, if the 189 does NOT cause different timing, than the >> >issue of a long >> > period (> 37 seconds) between the INVITE and 200 OK is not really >> >solved. I realize >> > this should be a very rare case.) >> > >> >/sean >> > >> >Rohan Mahy wrote: >> > >> >> Hi, >> >> >> >> I just submitted an ID for an extension to the REFER method that I >> >> discussed with Robert Sparks at Pittsburgh. Until it appears in the >> >> archive it is available at: >> >> >> >> ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-189-00.txt >> >> >> >> >> >> A SIP Extension: Informational Responses to the REFER method >> >> >> >> Abstract >> >> >> >> This document defines a SIP extension to the REFER method of the >> >> SIP Call Control Framework. This extension provides for the >> >> ability to convey information about the progress of the Referred >> >> request when that request is in a provisional state for a long >> >> period of time (many seconds or minutes). >> >> >> >> >> >> Comments welcome. >> >> >> >> thanks, >> >> -rohan >> >> >> >> >> > >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> 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 Nov 20 12:54:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09709 for ; Mon, 20 Nov 2000 12:54:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 034F2443E8; Mon, 20 Nov 2000 11:54:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 15C98443E6 for ; Mon, 20 Nov 2000 11:53:21 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id DC45A1E0A8; Mon, 20 Nov 2000 12:53:11 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA17541; Mon, 20 Nov 2000 12:53:11 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id MAA85731; Mon, 20 Nov 2000 12:53:02 -0500 (EST) Message-Id: <200011201753.MAA85731@fish-ha.research.att.com> To: aseem@trillium.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-manyfolks-resource-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 12:53:02 -0500 (EST) Aseem, The new draft, draft-ietf-sip-manyfolks-resource-00, is an update of previous draft-manyfolks-sip-resource-01. Since its name changed as a result of becomming a working group charter item, its version number was reset to zero. The previous contribution draft-ietf-mmusic-sdp-qos-00 expired in December 1999; it has been superceeded by the current draft, and its authors are some of the many folks. Bill Marshall wtm@research.att.com -----original message----- From: "Agarwal, Aseem" To: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-manyfolks-resource-00.txt Date: Mon, 13 Nov 2000 10:26:18 -0800 Hi, Is this document different from draft-manyfolks-sip-resource-01.txt ?? If not, should n't this document have a higher version number ? Also, does this draft obsolete "Establishing QOS and Security Preconditions for SDP Sessions", draft-ietf-mmusic-sdp-qos-00.txt ?? thanks, aseem _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 13:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18162 for ; Mon, 20 Nov 2000 13:29:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5BA6F4435D; Mon, 20 Nov 2000 12:29:08 -0500 (EST) 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 E3A2544349 for ; Mon, 20 Nov 2000 12:28:22 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA24238 for ; Mon, 20 Nov 2000 11:28:14 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA15247 for ; Mon, 20 Nov 2000 11:28:13 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 20 Nov 2000 12:28:13 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8693@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Subject: [SIP] VIA Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 12:28:12 -0600 What does the first 'VIA' describe? (The one with the maddr) Via: SIP/2.0/UDP 131.215.131.13;maddr=239.112.3.4;ttl=16; Via: SIP/2.0/TCP 10.0.1.1;received=128.13.44.52 Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 13:32: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 NAA18955 for ; Mon, 20 Nov 2000 13:32:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01047443B4; Mon, 20 Nov 2000 12:32:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id B41CD443B1 for ; Mon, 20 Nov 2000 12:31:02 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 12:30:17 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: SIP List Subject: Re: [SIP] New I-D on multiparty conferencing models Message-ID: <20001120123017.B9775@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Sun, Nov 19, 2000 at 10:19:19PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 12:30:17 -0600 I would like to thank both Jonathan and Henning for providing this important first step in allowing us to discuss conferencing in SIP. This helps both to clarify and focus future work. That said, I have some problems with the draft. I will start with the most critical. > 7 Centralized Signaling, Distributed Media > > In this conferencing model, there is a centralized controller, as > in the dial-in and dial-out cases. However, the centralized server > handles signaling only. The media is still sent directly between > participants, using either multicast or multi-unicast. > Multi-unicast is when a user sends multiple packets (one for each > recipient, addressed to that recipient). This is referred to as a > "Decentralized Multipoint Conference" in H.323. Interestingly, this > conference model is possible baseline SIP. > > It works through third party call control [13]. The conference > server uses re-INVITEs to each participant when a new one joins. > The re- INVITEs add a media stream that gets sent to the new > participant (and similarly in the reverse direction). I don't think this works. Let's look at some example SDP: ... c=24.22.33.44 m=audio 6646 RTP/AVP 0 c=33.24.44.22 m=audio 7348 RTP/AVP 1 Wouldn't this mean that if you use codec 0 then send to 24.22.33.44, and if you use codec 1 then send to 33.24.44.22? What document implies that I send using both codecs to each address? If you really want to do this, you're going to need a stronger description protocol. SDP just isn't good enough. UAs should not be expected to support this method as you describe. > 5 Ad-hoc Centralized Conferences > > [...] > > It is also possible to transition from a end system mixed > conference (even one with a complex connection topology), to a > centralized conference server. One user takes responsibility for > initiating the transition. It proceeds as described above. However, > the REFER request is sent to all SIP peers adjacent to the user. In > addition, when a SIP UA receives a REFER, they must not only act on > it as described above, but also generate a REFER to any of their > adjacent SIP peers. In essence, the REFER message is propagated > along the connection graph, starting at the root (which is the user > who initiates the transition). The transition will work so long as > the graph has no cycles (which is needed anyway, as discussed > above), and so long as only one user attempts to initiate the > transition. If multiple users attempt to initiate the transition at > the same time, the conference will break into two disjoint ad-hoc > conferences, with membership depending on the temporal dynamics of > the REFER propagation. This implies that REFER propagation should be automatic, but no method is given to signal this. It doesn't seem reasonable to expect UAs to propagate a REFER along their conferences. For example, say A is in a 3-way call performing End System Mixing: A D / \ B C And say that B REFERs A to D. Should A propagate this REFER to C? No. There is no way to know if D is a conference bridge or simply another phone. I think you should take this paragraph out. It is confusing and unnecessary in 99% of cases. If the user of A knows that D is a conference bridge, A can initiate a REFER to C if it wants to. This action should not be automatic. > 2.5 Discovering Participant Identities > > The identities of other participants in the conference is NOT known > through SIP. Rather, it is learned through RTP. UAs with degrees > greater than one are RTP mixers. As such, they take the RTCP SDES > of the streams they mix, and aggregrate them into the RTCP stream > sent out. Since RTCP messages are sent infrequently, there may be a > delay between when a user joins, and when their presence is known > to the other participants. You might want to mention in the security section that announcing participants via RTCP is not always desirable. For example, if the user wants someone to listen in on the call without announcing their presence to the remote agent. > 9 Whats Missing - Full Mesh > > [...] > > As a baseline model, we believe that each INVITE, 200 OK response, > and ACK simply contain a header called Members. This header is a > list of URLs, and for each URL, there is a parameter that indicates > whether they are in the conference right now, and when they joined, > or whether they were previously in the conference, and when they > left. A UA simply performs a re-INVITE as it receives new > information. A periodic re-INVITE (ala session timer [15] will also > be needed to heal partitions and deal with other conditions that > may arise). I don't think it is clean to try and put all that information into the SIP header. In my opinion, what is needed is first a generall call description language, which can describe the state of the conference as a whole. This is useful both for managing a full mesh call, or watching the status of a call through a conference bridge. See some old notes on conference control at: http://www.billybiggs.com/sip-conf/17-jun-00-conf-architecture-draft-1.txt Most of the document is useless, but I do talk about the need for a description language which is seperate from the control of the conference. I will attempt to update these notes based on your draft. One last note about your draft: > 2 End System Mixing > > [...] > > Note that this model has the serious drawback that the conference > ends when the mixing UA leaves the call. You can mention our Replaces draft. :) http://www.sip-happens.com/replaces/ -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 14:04:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24874 for ; Mon, 20 Nov 2000 14:04:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0BBFB4435E; Mon, 20 Nov 2000 13:04:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by lists.bell-labs.com (Postfix) with ESMTP id F25E844349 for ; Mon, 20 Nov 2000 13:03:35 -0500 (EST) Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id NAA25085; Mon, 20 Nov 2000 13:53:43 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525699D.0067CD96 ; Mon, 20 Nov 2000 13:53:48 -0500 X-Lotus-FromDomain: TELCORDIA From: "Sanjiv Deshpande" To: Baniel Uri-CUB001 Cc: "'sip@lists.bell-labs.com'" Message-ID: <8525699D.0067CC88.00@notes950.cc.telcordia.com> Subject: Re: [SIP] VIA Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=PZvHWorHNQbOCRiekOMh0VzEaGxbD7GjMRszN09DvlDv610N1vkVmM3W" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 13:53:32 -0500 --0__=PZvHWorHNQbOCRiekOMh0VzEaGxbD7GjMRszN09DvlDv610N1vkVmM3W Content-type: text/plain; charset=us-ascii Content-Disposition: inline Section 6.46.1------------ 2543bis. A client that sends a request to a multicast address MUST add the --0__=PZvHWorHNQbOCRiekOMh0VzEaGxbD7GjMRszN09DvlDv610N1vkVmM3W Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ?maddr? parameter to its Via header field, and SHOULD add the ?ttl? parameter. (In that case, the maddr par= ameter SHOULD contain the desti-nation multicast address, although under exceptional circumstances it MAY cont= ain a unicast address.) If a server receives a request which contained an ?maddr? parameter in the t= opmost Via field, it SHOULD send the response to the address listed in the ?maddr? parameter. Sanjiv. Baniel Uri-CUB001 on 11/20/2000 01:28:12 PM To: "'sip@lists.bell-labs.com'" cc: (bcc: Sanjiv Deshpande/Telcordia) Subject: [SIP] VIA = --0__=PZvHWorHNQbOCRiekOMh0VzEaGxbD7GjMRszN09DvlDv610N1vkVmM3W Content-type: text/plain; charset=us-ascii Content-Disposition: inline What does the first 'VIA' describe? (The one with the maddr) Via: SIP/2.0/UDP 131.215.131.13;maddr=239.112.3.4;ttl=16; Via: SIP/2.0/TCP 10.0.1.1;received=128.13.44.52 Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip --0__=PZvHWorHNQbOCRiekOMh0VzEaGxbD7GjMRszN09DvlDv610N1vkVmM3W-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 16:25:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19647 for ; Mon, 20 Nov 2000 16:25:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B63F144349; Mon, 20 Nov 2000 15:25:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id B692844348 for ; Mon, 20 Nov 2000 15:24:36 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA18086 for ; Mon, 20 Nov 2000 14:24:22 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA22632 for ; Mon, 20 Nov 2000 14:24:22 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 20 Nov 2000 15:24:13 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED869B@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] VIA response Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 15:24:20 -0600 Hello 2543bis section 1.4.3 SIP Transaction says: ..... If the request is sent via multicast UDP, the response is directed to the same multicast address and destination port. My question is: assume a UAC sends an INVITE, which goes via P1 and P2. The P2 multicast it to the multicast group MG1, which P3 happens to be one of its members. So to whom shall P3 return the response? is it to MG1? if that is the case, is P2 member of MG1? If yes why does the response go to the other group members ? Thanks Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 17:58:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04415 for ; Mon, 20 Nov 2000 17:58:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B3FFA44350; Mon, 20 Nov 2000 16:58:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1842744348 for ; Mon, 20 Nov 2000 16:57:25 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA03416; Mon, 20 Nov 2000 17:57:16 -0500 (EST) Message-ID: <3A19AC4C.782208EC@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Jonathan Rosenberg , SIP List Subject: Re: [SIP] New I-D on multiparty conferencing models References: <20001120123017.B9775@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: Mon, 20 Nov 2000 17:57:16 -0500 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > > 7 Centralized Signaling, Distributed Media > > > I don't think this works. > > Let's look at some example SDP: > > ... > c=24.22.33.44 > m=audio 6646 RTP/AVP 0 > c=33.24.44.22 > m=audio 7348 RTP/AVP 1 > > Wouldn't this mean that if you use codec 0 then send to 24.22.33.44, > and if you use codec 1 then send to 33.24.44.22? What document implies > that I send using both codecs to each address? SDP does. SDP does *not* say that you choose the media line you like. All media lines are sent simultaneously; unfortunately, this is implied (set of media) rather than stated. In practice, I doubt that any existing application will do this, but it has been done, e.g., for two simultaneous languages. The lack of distinction between 'and' and 'or' is a major flaw in SDP. > > If you really want to do this, you're going to need a stronger > description protocol. SDP just isn't good enough. > > UAs should not be expected to support this method as you describe. Indeed, I doubt that UAs will do this. They should support multiple media lines with the same type, however, as this is useful beyond this mixing model. -- 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 Nov 20 18:32: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 SAA08748 for ; Mon, 20 Nov 2000 18:32:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3982844374; Mon, 20 Nov 2000 17:32:09 -0500 (EST) 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 71DC744348 for ; Mon, 20 Nov 2000 17:31:55 -0500 (EST) 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 PAA09016; Mon, 20 Nov 2000 15:31:42 -0800 (PST) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ABE04654; Mon, 20 Nov 2000 17:31:41 -0600 (CST) Message-ID: <3A19B496.61897C69@cisco.com> From: Henry Chen X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Internet-Drafts@ietf.org Cc: IETF-Announce:@cisco.com, ";"@cisco.com, sip@lists.bell-labs.com Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-service-examples-00.txt References: <200011201117.GAA05328@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 17:32:38 -0600 Content-Transfer-Encoding: 7bit Hi: There are some inconsistencies for To Tag in the call flows. In 2.3 Consultation Hold: The To Tag "tag=314159" in F4 180 Ringing B -> Proxy 1 is copied to the From header in the F10 Invite request. But in 2.4 Unattended Transfer: The To Tag " tag=314159" in F3 ACK B -> A is copied to the To header in the F4 Invite request. According to RFC2543bis, 2.3 Consultation Hold is correct. Please confirm. Thanks, Henry 2.3 Consultation Hold ... /* User B places User A on hold. */ F10 INVITE B -> Proxy 1 INVITE sip:UserA@here.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 Route: From: LittleGuy ;tag=314159 To: BigGuy Call-ID: 12345601@here.com CSeq: 1 INVITE Contact: LittleGuy Content-Type: application/sdp Content-Length: ... The To Tag "tag=314159" in F4 180 Ringing B -> Proxy 1 is copied to From header in the F10 Invite request. 2.4 Unattended Transfer /* Session is established between A and B. User B then places User A on hold */ F4 INVITE A -> B INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: BigGuy To: LittleGuy ;tag=314159 Call-ID: 12345601@here.com CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: ... _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 18:57:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11997 for ; Mon, 20 Nov 2000 18:57:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FBBA4437D; Mon, 20 Nov 2000 17:57:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 1F39344367 for ; Mon, 20 Nov 2000 17:56:33 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 17:56:08 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , SIP List Subject: Re: [SIP] New I-D on multiparty conferencing models Message-ID: <20001120175608.A10358@div8.net> References: <20001120123017.B9775@div8.net> <3A19AC4C.782208EC@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A19AC4C.782208EC@cs.columbia.edu>; from hgs@cs.columbia.edu on Mon, Nov 20, 2000 at 05:57:16PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 17:56:08 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > > > 7 Centralized Signaling, Distributed Media > > > > > > I don't think this works. > > > > Let's look at some example SDP: > > > > ... > > c=24.22.33.44 > > m=audio 6646 RTP/AVP 0 > > c=33.24.44.22 > > m=audio 7348 RTP/AVP 1 > > > > Wouldn't this mean that if you use codec 0 then send to > > 24.22.33.44, and if you use codec 1 then send to 33.24.44.22? > > What document implies that I send using both codecs to each > > address? > > SDP does. SDP does *not* say that you choose the media line you like. > All media lines are sent simultaneously; unfortunately, this is > implied (set of media) rather than stated. In practice, I doubt that > any existing application will do this, but it has been done, e.g., for > two simultaneous languages. The lack of distinction between 'and' and > 'or' is a major flaw in SDP. Ok, so if I see: m=audio 6646 RTP/AVP 0 1 2 3 Then I get to choose, but if I see: m=audio 6646 RTP/AVP 0 m=audio 6656 RTP/AVP 1 Then I don't get to choose? I'm supposed to send to both? > > If you really want to do this, you're going to need a stronger > > description protocol. SDP just isn't good enough. > > > > UAs should not be expected to support this method as you describe. > > Indeed, I doubt that UAs will do this. They should support multiple > media lines with the same type, however, as this is useful beyond this > mixing model. Sorry, I don't follow. If I see: c=22.22.22.22 m=audio 6646 RTP/AVP 0 c=33.33.33.33 m=audio 6656 RTP/AVP 0 Then it's asking me to send to both of them? I don't think that anyone will support this either. I would say that it is too late for SDP, and if you want to signal this, lets define a stronger description protocol. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 19:05: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 TAA13083 for ; Mon, 20 Nov 2000 19:05:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F8174438B; Mon, 20 Nov 2000 18:05:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 299BD4437C for ; Mon, 20 Nov 2000 18:04:12 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA06936; Mon, 20 Nov 2000 19:03:59 -0500 (EST) Message-ID: <3A19BBEF.A23163A7@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Jonathan Rosenberg , SIP List Subject: Re: [SIP] New I-D on multiparty conferencing models References: <20001120123017.B9775@div8.net> <3A19AC4C.782208EC@cs.columbia.edu> <20001120175608.A10358@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: Mon, 20 Nov 2000 19:03:59 -0500 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > > Ok, so if I see: > m=audio 6646 RTP/AVP 0 1 2 3 > > Then I get to choose, but if I see: > m=audio 6646 RTP/AVP 0 > m=audio 6656 RTP/AVP 1 > > Then I don't get to choose? I'm supposed to send to both? Yes. Each m line is independent and additive. > Sorry, I don't follow. If I see: > c=22.22.22.22 > m=audio 6646 RTP/AVP 0 > c=33.33.33.33 > m=audio 6656 RTP/AVP 0 > > Then it's asking me to send to both of them? Yes. I believe that sdr actually allows this, but haven't tested this. > > I don't think that anyone will support this either. I would say that > it is too late for SDP, and if you want to signal this, lets define a > stronger description protocol. That's a separate and necessary step. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com -- 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 Nov 20 19:54:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19487 for ; Mon, 20 Nov 2000 19:54:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 77F2644338; Mon, 20 Nov 2000 18:54:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 3264F44336 for ; Mon, 20 Nov 2000 18:53:52 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 18:53:41 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , SIP List Subject: Re: [SIP] New I-D on multiparty conferencing models Message-ID: <20001120185341.A10435@div8.net> References: <20001120123017.B9775@div8.net> <3A19AC4C.782208EC@cs.columbia.edu> <20001120175608.A10358@div8.net> <3A19BBEF.A23163A7@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A19BBEF.A23163A7@cs.columbia.edu>; from hgs@cs.columbia.edu on Mon, Nov 20, 2000 at 07:03:59PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 18:53:41 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > > [...] but if I see: > > m=audio 6646 RTP/AVP 0 > > m=audio 6656 RTP/AVP 1 > > Then I don't get to choose? I'm supposed to send to both? > > Yes. Each m line is independent and additive. This means that I could be asked to commit a huge denial of service attack. There are security implications here. > > Sorry, I don't follow. If I see: > > c=22.22.22.22 > > m=audio 6646 RTP/AVP 0 > > c=33.33.33.33 > > m=audio 6656 RTP/AVP 0 > > > > Then it's asking me to send to both of them? > > Yes. I believe that sdr actually allows this, but haven't tested this. Again there are security implications. My client should be free to reject this SDP as if the caller didn't specify a supported codec. IIRC, this might be a 406 response and a shutdown of the call. The assertion in the draft that "Interestingly, this conference model is possible baseline SIP" is misleading. It implies that all SIP phones are expected to support it. I guess detecting the situation and shutting down the call is acceptable? > > I don't think that anyone will support this either. I would say > > that it is too late for SDP, and if you want to signal this, lets > > define a stronger description protocol. > > That's a separate and necessary step. Well, then maybe the problem is that SDP is too powerful for use as a base description protocol for SIP. If supporting SDP means supporting: - Sending audio to multiple locations, and - Mixing audio from multiple sources ... then I think that will exceed the capacity of many embedded phones. It also might simply be too difficult for others to code. Regardless, services which make use of these features must be aware that they will not be able to interoperate with everybody. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 20:02:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20478 for ; Mon, 20 Nov 2000 20:02:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 203774434A; Mon, 20 Nov 2000 19:02:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id BFE7244337 for ; Mon, 20 Nov 2000 19:01:05 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA09838; Mon, 20 Nov 2000 20:00:57 -0500 (EST) Message-ID: <3A19C949.4E3C6BE8@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Jonathan Rosenberg , SIP List Subject: Re: [SIP] New I-D on multiparty conferencing models References: <20001120123017.B9775@div8.net> <3A19AC4C.782208EC@cs.columbia.edu> <20001120175608.A10358@div8.net> <3A19BBEF.A23163A7@cs.columbia.edu> <20001120185341.A10435@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: Mon, 20 Nov 2000 20:00:57 -0500 Content-Transfer-Encoding: 7bit Frankly, I don't see the difference in allowing media to be sent to one address or two. There never was a guarantee that the media address is the same as the signaling address (3pcc works based on that principle). If you want denial of service, requesting a single video stream at high rate is a far more effective mechanism than some piddling audio streams... You don't need special SDP or end system capabilities for that "feature". -- 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 Nov 20 20:15: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 UAA21952 for ; Mon, 20 Nov 2000 20:15:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C62274438D; Mon, 20 Nov 2000 19:15:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 532BD44336 for ; Mon, 20 Nov 2000 19:14:24 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 19:14:06 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , SIP List Subject: Re: [SIP] New I-D on multiparty conferencing models Message-ID: <20001120191406.A10494@div8.net> References: <20001120123017.B9775@div8.net> <3A19AC4C.782208EC@cs.columbia.edu> <20001120175608.A10358@div8.net> <3A19BBEF.A23163A7@cs.columbia.edu> <20001120185341.A10435@div8.net> <3A19C949.4E3C6BE8@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A19C949.4E3C6BE8@cs.columbia.edu>; from hgs@cs.columbia.edu on Mon, Nov 20, 2000 at 08:00:57PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 19:14:06 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > Frankly, I don't see the difference in allowing media to be sent to > one address or two. There never was a guarantee that the media address > is the same as the signaling address (3pcc works based on that > principle). If you want denial of service, requesting a single video > stream at high rate is a far more effective mechanism than some > piddling audio streams... You don't need special SDP or end system > capabilities for that "feature". True, but you do need video. Regardless, lets just talk about the assumptions we're making about the capability of the clients. I don't expect all clients to be able to support: - sending audio to multiple locations, and - mixing audio from multiple sources. I don't think your draft should either. Is that unreasonable? -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 21:04:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27839 for ; Mon, 20 Nov 2000 21:04:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B2BAC44337; Mon, 20 Nov 2000 20:04:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from i3exchange.inin.com (mail.inter-intelli.com [204.180.46.4]) by lists.bell-labs.com (Postfix) with ESMTP id 20B7E44336 for ; Mon, 20 Nov 2000 20:01:51 -0500 (EST) Received: by i3exchange.inin.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 21:04:39 -0500 Message-ID: From: "Snyder, Duke" To: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] spaces in SIP-URL 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, 20 Nov 2000 21:04:38 -0500 Just to make sure I'm clear, is this true: Both SIP-URL and URI (as in the contact, to, from headers) can not contain spaces. Henning wrote: URLs, SIP or otherwise, cannot have unescaped spaces. Never have, never will. Anders Kristensen wrote: > > airoy@hss.hns.com wrote: > > > > you are pretty much on track....some additions are > > between the user and the "@" > > between the "@" and the host > > between host and " : " > > between ":" and port > > between port and ";" > > between ";" and url > > and so on...you have left out separators. You can have spaces or line > > folds between any 2 tokens , separators or otherwise. > > Why do you think spaces here are legal? As far as I can tell rfc 2396, > "Uniform Resource Identifiers (URI): Generic Syntax" seems to clearly > spaces in URIs altogether. The comments on "implied *LWS" in appendix B > of rfc 2543 doesn't change this. > > Anders > -- 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 Nov 20 21:10:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28558 for ; Mon, 20 Nov 2000 21:10:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 52C1C4438A; Mon, 20 Nov 2000 20:10:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DABD544384 for ; Mon, 20 Nov 2000 20:09:06 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA13534; Mon, 20 Nov 2000 21:08:58 -0500 (EST) Message-ID: <3A19D93A.8AA5D0BC@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Snyder, Duke" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] spaces in SIP-URL 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, 20 Nov 2000 21:08:58 -0500 Content-Transfer-Encoding: 7bit "Snyder, Duke" wrote: > > Just to make sure I'm clear, is this true: > Both SIP-URL and URI (as in the contact, to, from headers) can not contain > spaces. > > Henning wrote: > URLs, SIP or otherwise, cannot have unescaped spaces. Never > have, never > will. I'm sorry if my note was unclear, but the answer is that these URLs MUST NOT contain unescaped spaces (%20 is obviously ok where it makes sense). -- 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 Nov 20 21:15: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 VAA29155 for ; Mon, 20 Nov 2000 21:15:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C7D1443A9; Mon, 20 Nov 2000 20:15:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id C1582443A1 for ; Mon, 20 Nov 2000 20:14:22 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 20:14:12 -0600 (CST) From: Billy Biggs To: Alan Johnston Cc: Henry Chen , SIP List Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-service-examples-00.txt Message-ID: <20001120201412.B10526@div8.net> References: <200011201117.GAA05328@ietf.org> <3A19B496.61897C69@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A19B496.61897C69@cisco.com>; from hjlechen@cisco.com on Mon, Nov 20, 2000 at 05:32:38PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 20 Nov 2000 20:14:12 -0600 Henry Chen (hjlechen@cisco.com): > There are some inconsistencies for To Tag in the call flows. The example that Henry points out is of course a bug. Without having read the draft in depth, I would also like to request to the authors that From tags be inserted everywhere. From tags (on initial requests) are important for call-leg matching in the presence of forking proxies, which pretty much means everywhere. I don't want to encourage people not to use them. As well, it would be nice to see random tags per call. You have UserB always using the same tag. As I've mentioned before on this list, this is dangerous and a bad idea. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 20 21:20:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29773 for ; Mon, 20 Nov 2000 21:20:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8D8444379; Mon, 20 Nov 2000 20:20:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 7A80E44358 for ; Mon, 20 Nov 2000 20:19:33 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA14030; Mon, 20 Nov 2000 21:19:24 -0500 (EST) Message-ID: <3A19DBAC.271689BA@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-service-examples-00.txt References: <200011201117.GAA05328@ietf.org> <3A19B496.61897C69@cisco.com> <20001120201412.B10526@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: Mon, 20 Nov 2000 21:19:24 -0500 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > As well, it would be nice to see random tags per call. You have UserB > always using the same tag. As I've mentioned before on this list, this > is dangerous and a bad idea. Note that not everybody agrees with this. This is a trade-off between features. Different people come to different conclusions as to what the right trade-off is. -- 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 Nov 20 21:45:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04063 for ; Mon, 20 Nov 2000 21:45:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCB1B44361; Mon, 20 Nov 2000 20:45:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id D010644336 for ; Mon, 20 Nov 2000 20:44:30 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 20:44:19 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-service-examples-00.txt Message-ID: <20001120204419.A10597@div8.net> References: <200011201117.GAA05328@ietf.org> <3A19B496.61897C69@cisco.com> <20001120201412.B10526@div8.net> <3A19DBAC.271689BA@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A19DBAC.271689BA@cs.columbia.edu>; from hgs@cs.columbia.edu on Mon, Nov 20, 2000 at 09:19:24PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 20:44:19 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > > As well, it would be nice to see random tags per call. You have > > UserB always using the same tag. As I've mentioned before on this > > list, this is dangerous and a bad idea. > > Note that not everybody agrees with this. This is a trade-off between > features. Different people come to different conclusions as to what > the right trade-off is. Sorry, I didn't realize this was a contended issue. Right now the text reads, "[...] but it is RECOMMENDED to maintain the same tag across calls and instances of the UA to allow restarting of a user agent." If that is to be kept, then please also mention that UAs which exhibit this behavior be able to tell when a request loops back to themselves. This can happen in many cases, and I've seen UAs crash because they can't perform call-leg matching. Some cases: 1. User makes a call through a proxy which forks back to themselves (I called Joe but Joe has his calls forwarded to me). 2. User sends a SUBSCRIBE for their voicemail to sip:me@myproxy with an Accept-Contact: *;feature="voicemail", but the user doesn't have a voicemail server so the SUBSCRIBE comes back to the phone. 3. User calls themselves through their own proxy to make sure their registration is active. I mean, sure, UAs can have the logic inside them to detect this case, but in bis the suggestion is to always use the same tag without mention of them. You should also mention that soft-phones should avoid choosing a tag based on the MAC address. I think the how-to-create-a-crash-proof-SIP-UA stuff should be in a seperate document, not in the SIP RFC. It's more complicated than just choosing the same tag. You have to realize that Routes won't be kept, hope the far end sends a re-INVITE, etc... IMHO, recommending that UAs choose the same tag is asking for trouble. Does noone else agree? -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 00: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 SMTP id AAA00564 for ; Tue, 21 Nov 2000 00:10:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C933B44358; Mon, 20 Nov 2000 23:10:10 -0500 (EST) 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 2D1EB44336 for ; Mon, 20 Nov 2000 22:57:11 -0500 (EST) 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 KAA25496 for ; Tue, 21 Nov 2000 10:36:14 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA4056; Tue, 21 Nov 2000 10:17:39 +0530 Message-ID: <010701c05378$41006620$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Rohan Mahy" , "Sean Olson" Cc: References: <4.1.20001116151548.00cc2850@imop.cisco.com> <4.1.20001117102008.00a85c50@imop.cisco.com> <4.1.20001120093503.00cdc5c0@imop.cisco.com> Subject: Re: [SIP] ID extension of REFER MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 10:32:28 +0530 Content-Transfer-Encoding: 7bit The main reason as to why I am for forwarding provisional responses is as follows: This allows the "Transferror" to decide when he/she wants to hang up, very useful for certain applications, as I have mentioned in one of my previous posts, which I repeat here for completeness... Most transfers occur through a voice messaging system/IVR. Many of them support a couple of nice features where in on a transfer request, they want to know if the far end is busy, or if the far end is following a coverage path(on no answer), in which case they would want to abandon the transfer request, and then voice a message saying, "The transferred extension is busy/not available... To leave a message for please do so at the tone, to request another transfer press..." and so on. On the other hand, there are other simpler applications would just want to complete the transfer when they find the destination "ringing" and let the caller follow the coverage path of the TT in case of no answer(this is just to make sure that if the user mis-dialed and the voice messaging system did a blind transfer, the user will not be stuck listening to an overflow tone or would have to redial the entire number to reach another user). I saw lack of ability to cleanly support such applications with the original REFER based transfer solution. Your draft addresses this partly by sending a provisional response of some sort, and builds an excellent mechanism for supporting blind transfers(by dropping the necessity for the transferring UA to wait until a final response for REFER is received), but I think allowing provisional 1xx responses back to the transferring party would help continuing support for such existing applications. BTW, I thought the only consolidation that REFER provided as regards final response is that it consolidates a 3xx class response alone (Please correct me if I am wrong, but as far as I know, any 400-600 class responses MAY be issued in response to a REFER request. I don't know the rationale as to why only 1xx and 3xx level responses were masked). Venkatesh ----- Original Message ----- From: "Rohan Mahy" To: "Venkatesh Venkataramanan" ; "Sean Olson" Cc: Sent: Monday, November 20, 2000 11:08 PM Subject: Re: [SIP] ID extension of REFER > I am open to this option. Realize however, that REFER summarizes final > responses so summarizing provisionals is consistent with behavior that > exists today; and that simply forwarding other provisionals overloads their > semantics. > > thanks, > -rohan > > At 07:54 PM 11/18/00 , Venkatesh Venkataramanan wrote: > >Wouldn't simply forwarding the provisionals received allow the initiator of > >REFER know more about 'call progress' instead of translating them to a > >single 189 ? Are there any specific reasons against not doing so? Please > >elaborate. > > > >Venkatesh > >----- Original Message ----- > >From: "Rohan Mahy" > >To: "Sean Olson" > >Cc: > >Sent: Friday, November 17, 2000 11:58 PM > >Subject: Re: [SIP] ID extension of REFER > > > > > >> At 02:02 AM 11/17/00 , Sean Olson wrote: > >> >Hello, > >> > > >> >I am a little confused about the purpose of this I-D. The first question > >> >that springs to mind is > >> >why you don't use "183" for this purpose? > >> > >> the semantics of 183 already means something different, and i did not > >think > >> I could overload those semantics cleanly. > >> > >> >The second question is whether you > >> >intend the 189 to lead to different timing than any other provisional > >> >response? > >> > >> A sends REFER to B > >> B sends INVITE to C > >> > >> A would get 189s any time B got provisionals from C. > >> > >> If C just 200 OKs B's INVITE, no 189s are sent. > >> If C sends 180 or 183 and answers right away, A still gets a 189. If you > >> don't need the information you can ignore it. > >> > >> thanks, > >> -rohan > >> > >> >(In other words, if the 189 does NOT cause different timing, than the > >> >issue of a long > >> > period (> 37 seconds) between the INVITE and 200 OK is not really > >> >solved. I realize > >> > this should be a very rare case.) > >> > > >> >/sean > >> > > >> >Rohan Mahy wrote: > >> > > >> >> Hi, > >> >> > >> >> I just submitted an ID for an extension to the REFER method that I > >> >> discussed with Robert Sparks at Pittsburgh. Until it appears in the > >> >> archive it is available at: > >> >> > >> >> ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-189-00.txt > >> >> > >> >> > >> >> A SIP Extension: Informational Responses to the REFER method > >> >> > >> >> Abstract > >> >> > >> >> This document defines a SIP extension to the REFER method of the > >> >> SIP Call Control Framework. This extension provides for the > >> >> ability to convey information about the progress of the Referred > >> >> request when that request is in a provisional state for a long > >> >> period of time (many seconds or minutes). > >> >> > >> >> > >> >> Comments welcome. > >> >> > >> >> thanks, > >> >> -rohan > >> >> > >> >> > >> > > >> > >> > >> _______________________________________________ > >> SIP mailing list > >> SIP@lists.bell-labs.com > >> http://lists.bell-labs.com/mailman/listinfo/sip > >> > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 21 00:12:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00988 for ; Tue, 21 Nov 2000 00:12:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12BE744387; Mon, 20 Nov 2000 23:11:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.88.93]) by lists.bell-labs.com (Postfix) with ESMTP id 94ECF44336 for ; Mon, 20 Nov 2000 23:10:03 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id VAA06840 for ; Mon, 20 Nov 2000 21:05:10 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SIP] Record-Route consensus From: David Shrader To: SIP List Message-ID: In-Reply-To: <20001120095559.A9722@div8.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 23:59:00 -0500 Content-Transfer-Encoding: 7bit Where do we stand on which server removes the Route header? If I recall, the current spec says that the preceding server remotes the route header for the next destination. OTOH, I also saw posts suggesting that the server remove its own Route header (like the Via header). David ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com > From: Billy Biggs > Date: Mon, 20 Nov 2000 09:55:59 -0600 > To: Jo Hornsby > Cc: Sean Olson , "Fairlie-Cuninghame, Robert" > , SIP List > Subject: Re: [SIP] Record-Route consensus > > Jo Hornsby (jhornsby@ubiquity.net): > >> Right. So we're saying remove the bit where the bis specifies that >> the Request-URI is copied into the Record-Route, and instead note that >> the proxy is free to put any SIP URL in (of course, it should be >> routable); and also remove the bit where the bis specifies the Route >> Request-URI mangling by the called UA. > > Totally. It should put in some SIP URI that is routable in both > directions. > >>> Basically, you're just proposing that we don't allow non-SIP URIs >>> in the Route, and I think this is completely reasonable. >> >> Agreed. After all, we already say that a proxy is not allowed to >> mandate TCP (via the transport parameter) in Record-Route; allowing >> non-SIP URIs, I would say, is orders of magnitude more painful. > > Dude, you rock my world. > > Now, where's Sean Olson's argument? :) > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 00:45: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 AAA07821 for ; Tue, 21 Nov 2000 00:45:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E0534437C; Mon, 20 Nov 2000 23:45:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 235FA44336 for ; Mon, 20 Nov 2000 23:44:05 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 20 Nov 2000 23:43:55 -0600 (CST) From: Billy Biggs To: David Shrader Cc: SIP List Subject: Re: [SIP] Record-Route consensus Message-ID: <20001120234355.A10721@div8.net> References: <20001120095559.A9722@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from dshrader@master-consultant.com on Mon, Nov 20, 2000 at 11:59:00PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 20 Nov 2000 23:43:55 -0600 David Shrader (dshrader@master-consultant.com): > Where do we stand on which server removes the Route header? If I > recall, the current spec says that the preceding server remotes the > route header for the next destination. OTOH, I also saw posts > suggesting that the server remove its own Route header (like the Via > header). I don't recall that thread, but I can't see how it would help anything, and it would definitely break all existing implementations. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 04:03: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 EAA17225 for ; Tue, 21 Nov 2000 04:03:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5374F443BA; Tue, 21 Nov 2000 03:03:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 5E6884439A for ; Tue, 21 Nov 2000 03:02:30 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 21 Nov 2000 09:02:23 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA22678; Tue, 21 Nov 2000 10:00:58 +0100 (BST) Message-ID: <3A1A39C9.F05F7D37@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sip List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SRV Records for SIP on Win 2000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 21 Nov 2000 09:00:57 +0000 Content-Transfer-Encoding: 7bit We are looking to set up DNS SRV records for SIP servers at the upcoming bakeoff. Could anyone who has experience of doing this on a Win 2000 Server please get in touch to liaise with the hosts. Many thanks, Neil. (on behalf of the SIP Bake-off Technical Program Committee) -- 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 Nov 21 04:43:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21535 for ; Tue, 21 Nov 2000 04:43:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12774443CD; Tue, 21 Nov 2000 03:43:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 96862443C9 for ; Tue, 21 Nov 2000 03:42:06 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA12715; Tue, 21 Nov 2000 04:44:22 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 04:40:13 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , Jo Hornsby Cc: SIP List Subject: RE: [SIP] a stupid question on 3way handshake 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, 21 Nov 2000 04:40:12 -0500 > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Monday, November 20, 2000 10:26 AM > To: Jo Hornsby > Cc: SIP List > Subject: Re: [SIP] a stupid question on 3way handshake > > > Jo Hornsby (jhornsby@ubiquity.net): > > > Okay, so maybe Billy's suggestion was better: suggest sequential > > forking as nominal behaviour for non-INVITE. This doesn't > help at all > > with the OPTIONs case, but it's probably better for things like BYE, > > for instance. > > That's funny, because it seems completely reasonable to me > to parallel > fork a BYE. > > You would get a BYE at a proxy when the stupid UA at the other end > didn't put in a Contact. You want to shut down the call > quickly, so you > parallel fork to all registrations knowing that all but one > will return > a 481. Excellent point. Good case for forking a non-INVITE in parallel. Jo writes: > I think it's OPTIONS that bothers me the most. You try to gather > some information on the UA you're about to call with an OPTIONS, > and it forks. The result of the OPTIONS could be completely > useless, because it may well not be from the UA that you would > actually have ended up talking to if you'd done an INVITE instead. > > I don't know -- maybe it's a silly point, but forking just seems to > slightly spoil OPTIONS. Using OPTIONS to gather information on the UA you're about to call (beyond that there is a UA that you can talk to) has other problems. Service logic in a proxy may anyway dictate that the OPTIONS goes one way, and then a followup INVITE goes a different way (some kind of randomized load balancing). Furthermore, what would you realistically do with all the OPTIONS responses even if you could get them all? If you want to do something specific, like find out if there is a UA that supports video, you are far better off sending an OPTIONS with a caller preferences header. This way, if you get back any sucess responses, you know there is a UA that meets your requirements. Jo also writes: > Jonathan Rosenberg wrote: > > > > Well, its not evil, but its not correct. Proxies don't initiate > > requests on their own, excepting the "special" ones of BYE > > Do you mean CANCEL? Yes, sorry. -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 Nov 21 04:45:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21744 for ; Tue, 21 Nov 2000 04:45:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34008443D9; Tue, 21 Nov 2000 03:45:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 30C15443D8 for ; Tue, 21 Nov 2000 03:44:15 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA12729; Tue, 21 Nov 2000 04:46:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 04:42:22 -0500 Message-ID: From: Jonathan Rosenberg To: simon@firetalk.com, farhan Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIPFORUM] Re: [SIP] a stupid question on 3way handshake 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, 21 Nov 2000 04:42:22 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA21744 Please, lets use the sip list for technical discussions. I've removed the sip forum list from the to line. To answer your question: > -----Original Message----- > From: "ferreiro_j"@tsm.es [mailto:"ferreiro_j"@tsm.es] > Sent: Monday, November 20, 2000 10:59 AM > To: simon@firetalk.com; farhan > Cc: discussion@sipforum.org > Subject: Re: [SIPFORUM] Re: [SIP] a stupid question on 3way handshake > > > > > 11/20/2000 04:58 PM > (subscript: Javier Ferreiro Garcia@TSM) > > > >The INVITE retransmission will stop on receiving a > provisional response, so > >the ACK is needed to ensure the reliability (and stop > retransmission of) the > >final response. > > I´M NOT A DEVELOPER, BUT I UNDERSTAND THE ACK METHOD AS THE > BASIS FOR THE FORK > FUNCTIONALITY. > WHEN FORKING (i.e. SENDING MULTIPLE INVITE REQUESTS), THE > SESSION SHOULD NOT BE > AUTOMATICALLY ESTABLISHED WHEN THE CALLER RECEIVES THE INVITE > RESPONSE FROM THE > CALLEE, BUT RATHER WHEN THE CALLER ITSELF AGREES TO ESTABLISH > THE SESSION WITH > ANY PARTICULAR CALLEE FROM THE ONES THAT SENT A POSITIVE > INVITE RESPONSE. > IT ALLOWS IN THIS CASE THE CALLER TO SELECT ONE OF THE > PROPOSED LEGS, SENDING > THE ACK TO THE SELECTED ONE(s) AND CANCELLING THE REST OF THE PENDING > INVITATIONS. You wouldn't use CANCEL to terminate the other ones that have responded positively. For those, you would send BYE. CANCEL is only useful if the other end hasn't answered. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 04:47: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 EAA21982 for ; Tue, 21 Nov 2000 04:47:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A7DD2443E5; Tue, 21 Nov 2000 03:47:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DCB9E443E4 for ; Tue, 21 Nov 2000 03:46:57 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA12743; Tue, 21 Nov 2000 04:48:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 04:44:36 -0500 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP Registration minimal interval? 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, 21 Nov 2000 04:44:35 -0500 > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Monday, November 20, 2000 12:41 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] SIP Registration minimal interval? > > > Hi > Is there any 'floor limitation' on the registration interval? > I mean, let's say the registrar asks the client to register > every 20 minutes. > Can the client decide to register every 1 minute? If YES, do > we have any way to prevent malicious or badly configured > client from overloading the network? Yes, you would call the protocol police. I'll look the number up and send it to you :) Seriously, there is nothing a protocol can do to stop users from sending messages. Thats not a SIP thing, its an IP 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 Nov 21 04:59:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23299 for ; Tue, 21 Nov 2000 04:59:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58362443E4; Tue, 21 Nov 2000 03:59:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 307AC443CC for ; Tue, 21 Nov 2000 03:58:03 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 01:57:38 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'David Shrader'" , SIP List Subject: RE: [SIP] Record-Route consensus 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, 21 Nov 2000 01:57:35 -0800 DO that would _really_ confuse existing Record-Route proxies. We have a few options: 1) Scrap current mechanism completely and come up with something that works properly. This should have the benefits that new proxies will be ensured of the correct behaviour but it is not backwardly-compatiable with the old proxies (preferably violently so). Or 2) Cobble something together from old record-route system so that: a) old Record-Route proxies can still exist in the path (with known problems), but b) newer proxies can detect that the UAS will construct the reverse Route correctly and c) that older proxies will forward the Route entries correctly (assuming they implemented the spec correctly). Or lastly, 3) Cobble something together from old record route system so that: A proxy can't tell if the UAS or other older proxies are going to screw something up by using the old record-route behaviour. This is the worst possible solution. I think the current suggestions only fall into the last category which gives you the worst of both worlds. Think about it, if a proxy wants to be Record-Route'd there is a usually a reason for it. So it is next to useless if the proxy can only be "semi-sure" that it will correctly receive reverse requests. IMO opinion we need to come up with a RR proposal that is either pro-actively _not_ backwardly compatiable or that the proxy can at least detect that an older Record-Route scheme is being used by the UAS and/or other proxies. I have yet to hear suggestions falling into the second category..... so here's mine: - If the UAS receiving the Record-Routes was to put a special contact parameter into it's Contact then this would at least solve the "non-detection problem" of downstrea, proxies. - The UAS only changes the user@host:port part when building the reverse Route header (from From or COntact). This leaves all R-R parameter. This means that non-SIP Request-URI's should be work (and is backwards compat). - I beleive an older proxy would/should still pass the Record Route parameters onto the next hop (in the Request-URI) as long as you don't use angle brackets in the R-R header. That is, the record route parameters are actually treated as "other" URL parameters in the Request-URI (which is legal). This I think should fall into the second (most preferable) category. Comments? Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: David Shrader [mailto:dshrader@master-consultant.com] > Sent: Tuesday, November 21, 2000 12:59 PM > To: SIP List > Subject: Re: [SIP] Record-Route consensus > > > Where do we stand on which server removes the Route header? > If I recall, the > current spec says that the preceding server remotes the route > header for the > next destination. OTOH, I also saw posts suggesting that the > server remove > its own Route header (like the Via header). > > David > > ---------------------------- > David Shrader > Master Consultant, Inc. > dshrader@master-consultant.com > http://www.EyeForTheFuture.com > > > From: Billy Biggs > > Date: Mon, 20 Nov 2000 09:55:59 -0600 > > To: Jo Hornsby > > Cc: Sean Olson , > "Fairlie-Cuninghame, Robert" > > , SIP List > > Subject: Re: [SIP] Record-Route consensus > > > > Jo Hornsby (jhornsby@ubiquity.net): > > > >> Right. So we're saying remove the bit where the bis specifies that > >> the Request-URI is copied into the Record-Route, and > instead note that > >> the proxy is free to put any SIP URL in (of course, it should be > >> routable); and also remove the bit where the bis specifies > the Route > >> Request-URI mangling by the called UA. > > > > Totally. It should put in some SIP URI that is routable in both > > directions. > > > >>> Basically, you're just proposing that we don't allow non-SIP URIs > >>> in the Route, and I think this is completely reasonable. > >> > >> Agreed. After all, we already say that a proxy is not allowed to > >> mandate TCP (via the transport parameter) in Record-Route; allowing > >> non-SIP URIs, I would say, is orders of magnitude more painful. > > > > Dude, you rock my world. > > > > Now, where's Sean Olson's argument? :) > > > > -- > > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 21 05:13:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24890 for ; Tue, 21 Nov 2000 05:13:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAD31443CB; Tue, 21 Nov 2000 04:13:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9145644336 for ; Tue, 21 Nov 2000 04:12:23 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA12809; Tue, 21 Nov 2000 05:14:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 05:10:32 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , SIP List Subject: RE: [SIP] New I-D on multiparty conferencing models 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, 21 Nov 2000 05:10:31 -0500 > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Monday, November 20, 2000 7:54 PM > To: Henning G. Schulzrinne > Cc: Jonathan Rosenberg; SIP List > Subject: Re: [SIP] New I-D on multiparty conferencing models > > > Henning G. Schulzrinne (hgs@cs.columbia.edu): > > > > [...] but if I see: > > > m=audio 6646 RTP/AVP 0 > > > m=audio 6656 RTP/AVP 1 > > > Then I don't get to choose? I'm supposed to send to both? > > > > Yes. Each m line is independent and additive. > > This means that I could be asked to commit a huge denial of service > attack. There are security implications here. I don't see this as fundmentally different. I could specify a multicast address that has gazillions of receives, and do far more damage than enumerating a list of unicast addresses. Or, I could send you lots of INVITEs with different SDPs. You are always at liberty to implement policy to reject a call when you want. The point here is that there are legitimate, and indeed, useful cases where multiple m lines of the same type are present. This is one. If you read draft-rosenberg-sip-app-components, you will see other important uses that center around dtmf. I believe the use of multiple m lines is well within the spirit of SDP. Indeed, in the original model of a multicast, multimedia conference, this is quite reasonable. Consider a session thats a shuttle launch. I have one audio stream which is the launch itself, and a separate one which is the audio commentary from the reporter. I also have a video stream of it. Perfectly reasonable. Now, whether this is supported is a separate quesiton. Part of the motivation of this draft, and the 3pcc draft, is to show that these seemingly subtle things, if you do them, can open a wealth of services and features. 3pcc requires, for example, uses to accept re-INVITEs with modified connection addresses. SIP doesn't say anything specific about this. Likely people don't do it. The draft helps show why you should. In fact, at the last bakeoff, we had people who added support for it in order to enable 3pcc apps. > The assertion in the draft that "Interestingly, this > conference model > is possible baseline SIP" is misleading. It implies that all > SIP phones > are expected to support it. Right now, I expect no one supports it. Down the road, I would expect that many phones support it, and those that don't, reject the call with some reasonable response. I guess detecting the situation and > shutting down the call is acceptable? > > > > I don't think that anyone will support this either. I would say > > > that it is too late for SDP, and if you want to signal this, lets > > > define a stronger description protocol. > > > > That's a separate and necessary step. > > Well, then maybe the problem is that SDP is too powerful > for use as a > base description protocol for SIP. If supporting SDP means > supporting: > > - Sending audio to multiple locations, and > - Mixing audio from multiple sources > > ... then I think that will exceed the capacity of many embedded > phones. Mixing, perhaps. I'll note that I know of at least one embedded phone that does this, though. As for sending to multiple locations, thats trivial when the codec is the same. In fact, the RTP library we wrote, you can specify multiple unicast destinations when you set up the session, and it sends to all of them for you. > It also might simply be too difficult for others to code. I think you are overreacting a bit to the complexity involved for sending the same audio stream to multiple destinations. Billy initially wrote: > > It is also possible to transition from a end system mixed > > conference (even one with a complex connection topology), to a > > centralized conference server. One user takes responsibility for > > initiating the transition. It proceeds as described > above. However, > > the REFER request is sent to all SIP peers adjacent to > the user. In > > addition, when a SIP UA receives a REFER, they must not > only act on > > it as described above, but also generate a REFER to any of their > > adjacent SIP peers. In essence, the REFER message is propagated > > along the connection graph, starting at the root (which > is the user > > who initiates the transition). The transition will work > so long as > > the graph has no cycles (which is needed anyway, as discussed > > above), and so long as only one user attempts to initiate the > > transition. If multiple users attempt to initiate the > transition at > > the same time, the conference will break into two disjoint ad-hoc > > conferences, with membership depending on the temporal > dynamics of > > the REFER propagation. > > This implies that REFER propagation should be automatic, > but no method > is given to signal this. No signaling means is needed. The point here is that if a UA is doing this kind of mixing, and it receives a REFER, it has to propagate it for the conference to continue to function. Its a processing requirement that goes along with support for the model in general. Not all UAs that support REFER would do this; only ones actively performing this mixing role in a conference. > It doesn't seem reasonable to expect UAs to propagate a REFER along > their conferences. For example, say A is in a 3-way call performing > End System Mixing: > > A > D / \ > B C > > And say that B REFERs A to D. Should A propagate this REFER to C? > No. There is no way to know if D is a conference bridge or simply > another phone. Hmm. This is a good point. I could wave my hands here and say "well, B should know better than to transfer a multiparty call to a non-bridge entity". But, thats somewhat unsatisfying. There may be a need to signal whether REFER propagation is needed. I need to think about it. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 05:29:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26594 for ; Tue, 21 Nov 2000 05:29:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D5FEA443F8; Tue, 21 Nov 2000 04:29:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A5E3C443C9 for ; Tue, 21 Nov 2000 04:28:51 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA12830; Tue, 21 Nov 2000 05:31:09 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 05:27:01 -0500 Message-ID: From: Jonathan Rosenberg To: "'Stuart Wray'" , sip@lists.bell-labs.com Subject: RE: [SIP] URL comparison 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, 21 Nov 2000 05:27:00 -0500 > -----Original Message----- > From: Stuart Wray [mailto:Stuart.Wray@marconi.com] > Sent: Monday, November 20, 2000 10:15 AM > To: sip@lists.bell-labs.com > Subject: [SIP] URL comparison > > > > > Henning Schulzrinne suggested that I submit the following > questions about URL > comparison to the SIP list. > > On page 21 of rfc2543bis02 , it says > > (call this clause A) > "user, password, host, port and any url-parameter parameters > of the URI must > match. If a component is omitted, it matches based on its > default value." > > So far, this is clear, but the paragraph goes on to say that > > (call this clause B) > "Components not found in both URLs being compared are ignored" > > Now consider these two URLs: > > sip:juser@example.com:6666 > sip:juser@example.com > > Clause A means that these URLs compare as unequal, but clause > B means that they > compare as equal. > > Should clause B actually start with the word "other"? > > (clause B') > "Other components not found in both URLs being compared are ignored" > > (If so, is this actually the correct judgement? I would have > thought that a URL > should not compare equal to a URL with an extra component. > Why is it useful for > them to compare equal?) Hmm. Good question. I honestly can't recall why we said this. I would tend to agree that: sip:user@host:5050;foo=bar and sip:user@host:5050 are not the same. Unless someone can come up with a good reason why this should stay, I would argue that we change this to say "If one of the URLs has a component that is not present (and has no default value) in the other URL, the URLs are not equal". > > And now another separate point: the text on page 21 goes on to say: > > "Note that the two URLs example.com and example.com:5060, > while considered > equal, may not lead to the same server, as the former causes > a DNS SRV lookup, > while the latter only uses the A record". > > However, this is not true --- on page 12 it says: > > "3. The Request-URI is examined. If it contains an explicit > port number other > than 5060, the next two steps are skipped". > > The A record is only used if there is a port number other > than 5060 ---- so > example.com and example.com:5060 both use the SRV record. (Of > course this may > result in different machines actually being contacted, but > that's a different > matter entirely, not to do with A records). This is an error, I believe, resulting in the evolution of this text. We modified the SRV procedure so that example.com and example.com:5060 were, indeed, pointing to the same server, but didn't update the text on top which pointed out the problem. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 05:33:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27028 for ; Tue, 21 Nov 2000 05:33:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EA76A443FC; Tue, 21 Nov 2000 04:33:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id F1E3B443E0 for ; Tue, 21 Nov 2000 04:32:52 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 21 Nov 2000 10:32:46 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA01969; Tue, 21 Nov 2000 11:31:10 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , "'David Shrader'" , "SIP List" Subject: RE: [SIP] Record-Route consensus Message-ID: <000b01c053a6$2a24b860$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, 21 Nov 2000 10:31:10 -0000 Content-Transfer-Encoding: 7bit Robert Fairlie-Cuninghame wrote: > > We have a few options: > 1) Scrap current mechanism completely and come up with something > that works properly. This should have the benefits that new > proxies will be ensured of the correct behaviour but it is not > backwardly-compatiable with the old proxies (preferably violently > so). > > Or > 2) Cobble something together from old record-route system so that: > a) old Record-Route proxies can still exist in the path (with known > problems), but > b) newer proxies can detect that the UAS will construct the reverse > Route correctly and > c) that older proxies will forward the Route entries correctly > (assuming they implemented the spec correctly). > > Or lastly, > 3) Cobble something together from old record route system so that: > A proxy can't tell if the UAS or other older proxies are going to > screw something up by using the old record-route behaviour. > This is the worst possible solution. I'm not sure how you come to this conclusion. If I requote 2543, section 6.29: The server copies the Record-Route header field unchanged into the response. (Record-Route is only relevant for 2xx responses.) 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. If the response contained a Contact header field, the calling user agent adds its content as the last Route header. Unless this would cause a loop, any client MUST send any subsequent requests for this call leg to the first Request-URI in the Route request header field and remove that entry. If I were feeling particularly uncharitable, then I would say a (calling) 2543-compliant UA that did not copy _all_ of the URI parameters was seriously broken -- it had no business assuming that it was allowed to mangle the Record-Route values in any way. Further, looking to section 2 of the same: The transport, maddr, and ttl parameters MUST NOT be used in the From and To header fields and the Request-URI; they are ignored if present. Headers: Headers of the SIP request can be defined with the "?" mechanism within a SIP URL. The special hname "body" indicates that the associated hvalue is the message-body of the SIP INVITE request. Headers MUST NOT be used in the From and To header fields and the Request-URI; they are ignored if present. hname and hvalue are encodings of a SIP header name and value, respectively. All URL reserved characters in the header names and values MUST be escaped. Method: The method of the SIP request can be specified with the method parameter. This parameter MUST NOT be used in the From and To header fields and the Request-URI; they are ignored if present. Therefore, a 2543-compliant client (be it proxy or UA) again would have no business removing any parameters that it did not recognise, besides the ones listed above. It's a bit of a shame that maddr was included, but we don't actually need that parameter with this proposal, anyway. &:) > I think the current suggestions only fall into the last category > which gives you the worst of both worlds. Think about it, if a > proxy wants to be Record-Route'd there is a usually a reason > for it. So it is next to useless if the proxy can only be > "semi-sure" that it will correctly receive reverse requests. This is true -- I find it very unlikely that 2543-compliant called UAs would ever do The Right Thing when sending requests; however, in the end, even ensuring that one is a pure 3000 (imaginary new RFC) network, isn't enough in itself. That is because UAs can still misbehave -- maliciously, or otherwise. Record-Route is a mechanism that allows proxies to ask that they are kept in the signalling path; however, they can't insist such that the signalling path will be torn down if they are not. If a proxy is to know that it's going to stay in the signalling path, then it will be achieved with trust relationships, and various networking magic. Most often, this will probably consist of talking to vendors/service-providers that offer guarantees; and ultimately, I think that this is the best that one can do. > IMO opinion we need to come up with a RR proposal that is either > pro-actively _not_ backwardly compatiable or that the proxy can at least > detect that an older Record-Route scheme is being used by the UAS and/or > other proxies. > > I have yet to hear suggestions falling into the second category..... so > here's mine: > > - If the UAS receiving the Record-Routes was to put a special contact > parameter into it's Contact then this would at least solve the > "non-detection problem" of downstrea, proxies. > - The UAS only changes the user@host:port part when building the reverse > Route header (from From or COntact). This leaves all R-R parameter. This > means that non-SIP Request-URI's should be work (and is backwards compat). > - I beleive an older proxy would/should still pass the Record Route > parameters onto the next hop (in the Request-URI) as long as you don't use > angle brackets in the R-R header. That is, the record route > parameters are > actually treated as "other" URL parameters in the Request-URI (which is > legal). > > This I think should fall into the second (most preferable) category. > > Comments? This will work -- of course. It's just that I see no real need to make the differentiation (old vs. new), when on paper (ignoring bis (:&), we already have interoperation[0]. Cheers, - Jo. [0] With new UAs that don't mangle the Route Request-URIs, of course. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 06:27: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 GAA04488 for ; Tue, 21 Nov 2000 06:27:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F95A443C7; Tue, 21 Nov 2000 05:27:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A47EB44336 for ; Tue, 21 Nov 2000 05:26:41 -0500 (EST) Received: from dynamicsoft.com ([212.120.151.67]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA12945; Tue, 21 Nov 2000 06:28:55 -0500 (EST) Message-ID: <3A1A5BAC.A0975580@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nissen Cc: jainsip@Sun.COM, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A16922C.EFDE9019@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 11:25:32 +0000 Content-Transfer-Encoding: 7bit Erik, The implication of what you say is that all set methods in the header interfaces which take String arguments must throw a checked JainSipParseException. I think this is reasonable given that different implementations will be more tolerant than others. However, in order to allow lazy parsing by an implementation, all get methods in the header interfaces (regardless of return type) must throw a checked parse exception. This is a lot of checked exceptions - and will make life more awkward for the application developer. It would certainly be much less effort to not allow lazy parsing - there would be no need to throw a parse exception for all get methods - greatly reducing the number of checked exceptions. Unfortunately it has been said that JAIN SIP support for lazy parsing is a must. If it is then I guess there is no other choice than to include the exceptions? Regards, Chris Erik Nissen wrote: > Chris Harris wrote: > > > > > We need to decide whether this should be a checked or runtime exception. > > The rule of thumb is to use: > * checked exceptions when the program should handle situations which > can/will occur. > * runtime exceptions when there are programming error (God forbid :-) > > So: > Parse errors should throw checked exceptions. > Becaurse parse errors are outside the control of the programmer > and he/she should be forced to handle such conditions in the code. > > Null/wrong arguments should throw runtime exceptions. > > If it is possible, reduce the number of methods throwing (checked) > exceptions > to a minimum. > > Best regards, > /Erik Nissen, > Ericsson Utveckling AB _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 06:29:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04746 for ; Tue, 21 Nov 2000 06:29:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D39244400; Tue, 21 Nov 2000 05:29:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 4D17D443F4 for ; Tue, 21 Nov 2000 05:28:17 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 03:27:52 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Record-Route consensus 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, 21 Nov 2000 03:27:52 -0800 Jo, you're right, I was referring the to "new" old Record-Route scheme presented in the bis draft not the "old" old RFC2543 R-R scheme. [ I also admit to a fading memory of the old RFC specifics :) ] Its the Route mangling in the _UAS_ (not the proxies) that is causing us the grief now (ala the bis). The route mangling was to maintain the protocol invariant of the Request-URI (not very well) which even JR agrees might be causing more pain than its worth. One could say "why bother worrying about backwards compat - nobody implemented the Route mangling anyway". Is this true? Or have a sufficient number of UAS's implemented this to make it worthwhile to put some thought into detecting if Route mangling will not occur ? If it is not worthwhile worrying about bis implementations, then the fix is simple, right? Each proxy simply puts its own globally routeable address into the Record-Route URL and then go back to the simpler RFC2543 behaviour. Otherwise, well we also have to have the UAS do something indicative that the "new old old" behaviour is implemented. I think I can guess what the consensus will be, "Don't worry, be happy." I think I would tend to agree. :) [As an aside, IMO, the argument that a mutual trust relationship is required to ensure a proxy stays in the signalling path, doesn't apply to justifying why something can't be _expected_ to succeed between a set of co-operating (ie, non-intentionally-malicous) UA and proxies]. Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Tuesday, November 21, 2000 6:31 PM > To: Fairlie-Cuninghame, Robert; 'David Shrader'; SIP List > Subject: RE: [SIP] Record-Route consensus > > > Robert Fairlie-Cuninghame wrote: > > > > We have a few options: > > 1) Scrap current mechanism completely and come up with something > > that works properly. This should have the benefits that new > > proxies will be ensured of the correct behaviour but it is not > > backwardly-compatiable with the old proxies (preferably violently > > so). > > > > Or > > 2) Cobble something together from old record-route system so that: > > a) old Record-Route proxies can still exist in the path (with known > > problems), but > > b) newer proxies can detect that the UAS will construct the reverse > > Route correctly and > > c) that older proxies will forward the Route entries correctly > > (assuming they implemented the spec correctly). > > > > Or lastly, > > 3) Cobble something together from old record route system so that: > > A proxy can't tell if the UAS or other older proxies are going to > > screw something up by using the old record-route behaviour. > > This is the worst possible solution. > > I'm not sure how you come to this conclusion. > > If I requote 2543, section 6.29: > > The server copies the Record-Route header field unchanged into the > response. (Record-Route is only relevant for 2xx responses.) > > 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. If the response contained a > Contact header > field, the calling user agent adds its content as the last Route > header. Unless this would cause a loop, any client MUST send any > subsequent requests for this call leg to the first > Request-URI in the > Route request header field and remove that entry. > > If I were feeling particularly uncharitable, then I would say a > (calling) 2543-compliant UA that did not copy _all_ of the URI > parameters was seriously broken -- it had no business assuming > that it was allowed to mangle the Record-Route values in any > way. > > Further, looking to section 2 of the same: > > The transport, maddr, and ttl parameters MUST NOT be used > in the From > and To header fields and the Request-URI; they are ignored if > present. > > Headers: Headers of the SIP request can be defined with the "?" > mechanism within a SIP URL. The special hname "body" indicates > that the associated hvalue is the message-body of the > SIP INVITE > request. Headers MUST NOT be used in the From and To header > fields and the Request-URI; they are ignored if > present. hname > and hvalue are encodings of a SIP header name and value, > respectively. All URL reserved characters in the header names > and values MUST be escaped. > > Method: The method of the SIP request can be specified with the > method parameter. This parameter MUST NOT be used in the From > and To header fields and the Request-URI; they are ignored if > present. > > Therefore, a 2543-compliant client (be it proxy or UA) again would > have no business removing any parameters that it did not recognise, > besides the ones listed above. It's a bit of a shame that maddr > was included, but we don't actually need that parameter with this > proposal, anyway. &:) > > > I think the current suggestions only fall into the last category > > which gives you the worst of both worlds. Think about it, if a > > proxy wants to be Record-Route'd there is a usually a reason > > for it. So it is next to useless if the proxy can only be > > "semi-sure" that it will correctly receive reverse requests. > > This is true -- I find it very unlikely that 2543-compliant called > UAs would ever do The Right Thing when sending requests; however, > in the end, even ensuring that one is a pure 3000 (imaginary new > RFC) network, isn't enough in itself. > > That is because UAs can still misbehave -- maliciously, or > otherwise. Record-Route is a mechanism that allows proxies to > ask that they are kept in the signalling path; however, they > can't insist such that the signalling path will be torn down > if they are not. > > If a proxy is to know that it's going to stay in the signalling > path, then it will be achieved with trust relationships, and > various networking magic. Most often, this will probably > consist of talking to vendors/service-providers that offer > guarantees; and ultimately, I think that this is the best that > one can do. > > > IMO opinion we need to come up with a RR proposal that is either > > pro-actively _not_ backwardly compatiable or that the proxy > can at least > > detect that an older Record-Route scheme is being used by > the UAS and/or > > other proxies. > > > > I have yet to hear suggestions falling into the second > category..... so > > here's mine: > > > > - If the UAS receiving the Record-Routes was to put a > special contact > > parameter into it's Contact then this would at least solve the > > "non-detection problem" of downstrea, proxies. > > - The UAS only changes the user@host:port part when > building the reverse > > Route header (from From or COntact). This leaves all R-R > parameter. This > > means that non-SIP Request-URI's should be work (and is > backwards compat). > > - I beleive an older proxy would/should still pass the Record Route > > parameters onto the next hop (in the Request-URI) as long > as you don't use > > angle brackets in the R-R header. That is, the record route > > parameters are > > actually treated as "other" URL parameters in the > Request-URI (which is > > legal). > > > > This I think should fall into the second (most preferable) category. > > > > Comments? > > This will work -- of course. It's just that I see no real need > to make the differentiation (old vs. new), when on paper (ignoring > bis (:&), we already have interoperation[0]. > > Cheers, > > > - Jo. > > [0] With new UAs that don't mangle the Route Request-URIs, of course. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 07:01:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10012 for ; Tue, 21 Nov 2000 07:01:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1FF4E44404; Tue, 21 Nov 2000 06:01:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 2E40A443D8 for ; Tue, 21 Nov 2000 06:00:12 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 21 Nov 2000 12:00:05 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA10107; Tue, 21 Nov 2000 12:58:37 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" Cc: Subject: RE: [SIP] Record-Route consensus Message-ID: <001201c053b2$62326d90$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, 21 Nov 2000 11:58:38 -0000 Content-Transfer-Encoding: 7bit Robert Fairlie-Cuninghame wrote: > > Jo, you're right, I was referring the to "new" old Record-Route scheme > presented in the bis draft not the "old" old RFC2543 R-R scheme. [ I also > admit to a fading memory of the old RFC specifics :) ] Oh, right! &:) > Its the Route > mangling in the _UAS_ (not the proxies) that is causing us the grief now > (ala the bis). The route mangling was to maintain the protocol > invariant of > the Request-URI (not very well) which even JR agrees might be causing more > pain than its worth. > > One could say "why bother worrying about backwards compat - nobody > implemented the Route mangling anyway". Is this true? Or have a sufficient > number of UAS's implemented this to make it worthwhile to put some thought > into detecting if Route mangling will not occur ? > > If it is not worthwhile worrying about bis implementations, then > the fix is > simple, right? Each proxy simply puts its own globally routeable address > into the Record-Route URL and then go back to the simpler RFC2543 > behaviour. > Otherwise, well we also have to have the UAS do something indicative that > the "new old old" behaviour is implemented. Very much so. I was basically working on the premise of "screw the current bis". &:) As you've noted, I don't think we can have one solution which will work across the board. > [As an aside, IMO, the argument that a mutual trust relationship > is required to ensure a proxy stays in the signalling path, doesn't > apply to justifying why something can't be _expected_ to succeed > between a set of co-operating (ie, non-intentionally-malicous) UA > and proxies]. True. True. However, I think it's likely in practise that UAs will be "required" to conform to RFC N (where N is the next SIP RFC, or whatever), if they are going to be used in certain networks; this is what I was alluding (albeit poorly) to. 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 Nov 21 07:27: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 HAA14692 for ; Tue, 21 Nov 2000 07:27:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3B5D9443F4; Tue, 21 Nov 2000 06:27:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 6EFC444336 for ; Tue, 21 Nov 2000 06:25:59 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 21 Nov 2000 12:25:52 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA23854; Tue, 21 Nov 2000 13:24:17 +0100 (BST) From: "Jo Hornsby" To: "Billy Biggs" , "Henning G. Schulzrinne" Cc: "Alan Johnston" , "Henry Chen" , "SIP List" Message-ID: <001501c053b5$f7d91940$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: <20001120204419.A10597@div8.net> Subject: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 12:24:17 -0000 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > If that is to be kept, then please also mention that UAs which exhibit > this behavior be able to tell when a request loops back to themselves. > This can happen in many cases, and I've seen UAs crash because they > can't perform call-leg matching. > > Some cases: > > 1. User makes a call through a proxy which forks back to themselves (I > called Joe but Joe has his calls forwarded to me). > > 2. User sends a SUBSCRIBE for their voicemail to sip:me@myproxy with > an Accept-Contact: *;feature="voicemail", but the user doesn't have > a voicemail server so the SUBSCRIBE comes back to the phone. Am I right in thinking that both of these cases are reasonably easily solved if the UA always inserts a From tag, too; or is the problem more subtle than that? 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 Nov 21 08:16: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 IAA24365 for ; Tue, 21 Nov 2000 08:16:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3602F443E0; Tue, 21 Nov 2000 07:16:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.au.ac.th (home.au.ac.th [202.6.101.20]) by lists.bell-labs.com (Postfix) with ESMTP id 45F2A44336 for ; Tue, 21 Nov 2000 01:59:02 -0500 (EST) Received: from au1.au.ac.th (au1.au.ac.th [202.6.101.1]) by mail.au.ac.th (Postfix) with ESMTP id BF8444B44 for ; Tue, 21 Nov 2000 14:58:16 +0700 (GMT) Received: from localhost (pop@localhost) by au1.au.ac.th (8.9.1/8.9.1) with ESMTP id OAA06370 for ; Tue, 21 Nov 2000 14:53:21 +0700 (GMT) X-Authentication-Warning: au1.au.ac.th: pop owned process doing -bs From: Voravit Hirunadisuan X-Sender: pop@au1.au.ac.th To: sip list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] About SDP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 21 Nov 2000 14:53:20 +0700 (GMT) Dear all Is there any SDP API public for common usage? Mr. Voravit H. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 08:44: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 IAA29408 for ; Tue, 21 Nov 2000 08:44:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 83B8B4440F; Tue, 21 Nov 2000 07:44:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id EC3FB44336 for ; Tue, 21 Nov 2000 07:43:19 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XKW3XB94; Tue, 21 Nov 2000 14:40:41 +0100 From: "Hisham Khartabil" To: Subject: RE: [SIP] Contact header is a 200 response to SUBSCRIBE for IMPP 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 15:44:09 +0200 Content-Transfer-Encoding: 7bit Hi, I'm posting the following again since there was no reply the first time around Regards, Hisham Khartabil Hotsip Finland www.hotsip.com -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Hisham Khartabil Sent: Thursday, 9 November 2000 11:41 AM To: sip@lists.bell-labs.com Subject: [SIP] Contact header is a 200 response to SUBSCRIBE for IMPP Section 4.2 of the presence draft has the following examples: SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0 Via: SIP/2.0/UDP userpc.example.com To: sip:jdrosen@dynamicsoft.com From: sip:user@example.com Contact: sip:user@userpc.example.com Call-ID: knsd08alas9dy@3.4.5.6 CSeq: 1 SUBSCRIBE Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP presenceserver.dynamicsoft.com Via: SIP/2.0/UDP userpc.example.com To: sip:jdrosen@dynamicsoft.com From: sip:user@example.com Contact: sip:user@userpc.example.com Record-Route: sip:jdrosen@example.com;maddr=presenceserver.dynamicsoft.com Expires: 3600 Call-ID: knsd08alas9dy@3.4.5.6 CSeq: 1 SUBSCRIBE Content-Type: application/xpidf+xml Content-Length: 287
Then, it goes on to say: "Notice that the response has mirrored many fields from the request,including the To, From, Call-ID, CSeq, and Via headers. The PA has also added a Contact header, providing an address where it can be reached. The response also contains a Record-Route header. This header was presumably inserted by the proxy (the address in the maddr header is that of a presence server acting as a proxy), and is reflected in the 200 OK response. The response also contains a presence document for the presentity, and a Contact header. The Contact headers in a response to SUBSCRIBE list all the current addresses which have been subscribed." The example shows that the Contact header in the response does actually list the current address which has been subscribed (user@userpc.example.com). But I fail to see where the Contact header that the PA added providing an address where it can be reached. Regards, Hisham Khartabil Hotsip Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 08:46: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 IAA29909 for ; Tue, 21 Nov 2000 08:46:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A27EC44415; Tue, 21 Nov 2000 07:45:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 1B92C44414 for ; Tue, 21 Nov 2000 07:44:44 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XKW3XB99; Tue, 21 Nov 2000 14:42:25 +0100 From: "Hisham Khartabil" 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.50.4133.2400 Subject: [SIP] SIP Extensions for Presence Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 15:45:53 +0200 Content-Transfer-Encoding: 7bit Take 2: Hi all, Apologies for the long email, but I have few questions regarding SIP Extensions for Presence. 3. Definitions "Presence User Agent (PUA): A Presence User Agent manipulates presence information for a presentity. In SIP terms, this means that a PUA generates REGISTER requests, conveying some kind of information about the presentity." "Presence Agent (PA): A presence agent is a SIP user agent which is capable of receiving SUBSCRIBE requests, responding to them, and generating notifications of changes in presence state." Q: what about the sip user agent that generates SUBSCRIBE request and receiving notifications? Should we have a definition for that? Are we assuming s/he is the SUBSCRIBER? 4.2 Message Flow ... "In fact, it is possible that two different presence clients register for the same presentity. In this case, the presence server, acting as a proxy, may fork the SUBSCRIBE, which means it sends multiple copies of the request, one to each presence client. Each client will presumably query its principal about whether the subscription is acceptable. In the common case where a principal has left their presence tool running at work, and then gone home and started the tool there, the principal will accept the subscription at home. This causes a success response to be generated, and forwarded to the presence server (which is acting as a proxy), and then back to the subscriber. The presence tool at home then assumes responsibility for that subscription. The tool at work can continue to support subscriptions it received previously." Since I am not at work, my status will not change so no notifications will be generated. This does not give the subscriber and up to date notification of my presence. Q: how about if I don't want my subscriptions at work to continue and I want them to be transferred home? I know this is achieved over time since SUBSCRIBE has Expires: header. But this could take hours (or one hour). There should be a way to transfer subscriptions. ... "As an optimization, notifications do not need to be sent if the subscriber is not actually online. This improves scalability." Q: is this assuming that A is subscribed to B and vice versa? Otherwise, who would a Presence Agent Know that the subscriber on offline? ... "A SUBSCRIBE request MUST contain a Contact header. This indicates the address(es) (as a SIP URL) to which the client would like to receive notifications. This MUST be be one or more SIP addresses, containing the fully qualified domain names for the host generating the subscription, or the IP address of the host generating the subscription. Other addresses are possible, supporting third party subscriptions. If it contains multiple addresses, notifications will be sent to each address. If no Contact header is present, no notifications will be sent." Q: since a SUBSCRIBE request MUST contain a Contact header, why wouldn't you respond with 4xx if no Contact is present? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 08:49: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 IAA00639 for ; Tue, 21 Nov 2000 08:49:28 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0BE9644414; Tue, 21 Nov 2000 07:48:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id EB45D44336 for ; Tue, 21 Nov 2000 07:47:51 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XKW3XB0Q; Tue, 21 Nov 2000 14:45:33 +0100 From: "Hisham Khartabil" 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.50.4133.2400 Subject: [SIP] Presence Server with Client Notification Example Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 21 Nov 2000 15:49:01 +0200 Content-Transfer-Encoding: 7bit Hi, The REGISTER message in example 13.2 of the SIP for Presence draft has the method in the Contact header as method=MESSAGE. It should say SUBSCRIBE. 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 Tue Nov 21 09:14:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05429 for ; Tue, 21 Nov 2000 09:14:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BA0ED44413; Tue, 21 Nov 2000 08:14:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 7642D4440E for ; Tue, 21 Nov 2000 08:13:37 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 21 Nov 2000 08:13:12 -0600 (CST) From: Billy Biggs To: Jo Hornsby Cc: "Henning G. Schulzrinne" , Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) Message-ID: <20001121081312.B11312@div8.net> References: <20001120204419.A10597@div8.net> <001501c053b5$f7d91940$4e34c3c1@ubiquity.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <001501c053b5$f7d91940$4e34c3c1@ubiquity.co.uk>; from jhornsby@ubiquity.net on Tue, Nov 21, 2000 at 12:24:17PM -0000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 21 Nov 2000 08:13:12 -0600 Jo Hornsby (jhornsby@ubiquity.net): > Billy Biggs wrote: > > If that is to be kept, then please also mention that UAs which > > exhibit this behavior be able to tell when a request loops back to > > themselves. This can happen in many cases, and I've seen UAs > > crash because they can't perform call-leg matching. > > > > Some cases: > > > > 1. User makes a call through a proxy which forks back to > > themselves (I called Joe but Joe has his calls forwarded to > > me). > > > > 2. User sends a SUBSCRIBE for their voicemail to sip:me@myproxy > > with an Accept-Contact: *;feature="voicemail", but the user > > doesn't have a voicemail server so the SUBSCRIBE comes back to > > the phone. > > Am I right in thinking that both of these cases are reasonably easily > solved if the UA always inserts a From tag, too; or is the problem > more subtle than that? Their suggestion was that the UA always use the same local tag so when you're rebooted and see a re-INVITE you know not to return a 481 cause it's actually for you. It's in bis-02. For that to work, the UA will always put in a from tag on outgoing requests, but it will always be the same. As well, the UA will always answer with the same to tag on outgoing responses. So, UA sends a request, it loops back, they end up putting the same tag as the To and as the From... You see the problem? Call-leg endpoint matching is based on: call-id,local-uri,local-tag,remote-uri,remote-tag And you'll end up with the same key for both. The code gets cleaner if you always pick random tags. Unfortunately, call-leg-end matching is very difficult. As an aside, things would be alot more robust if tags were mandatory. Ideally, I want to match on: call-id,local-tag,remote-tag (or for an unconnected call-leg end): call-id,local-tag Much nicer than this total hack of trying to compare the URIs, especially when they aren't SIP URIs. Oh well. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 09:28:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08171 for ; Tue, 21 Nov 2000 09:28:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7892244421; Tue, 21 Nov 2000 08:28:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6FCEC44336 for ; Tue, 21 Nov 2000 08:27:25 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA15738; Tue, 21 Nov 2000 09:27:12 -0500 (EST) Message-ID: <3A1A8640.4166E73C@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Baniel Uri-CUB001'" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] SIP Registration minimal interval? 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, 21 Nov 2000 09:27:12 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > > Yes, you would call the protocol police. I'll look the number up and send it > to you :) > > Seriously, there is nothing a protocol can do to stop users from sending > messages. Thats not a SIP thing, its an IP thing. > At least in the United States, interfering with the operation of a computer system can be a federal offense, so you can indeed call the FBI as the "protocol police". Yahoo and others did when they were on the receiving end of various DDOS attacks. -- 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 Nov 21 10: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 KAA23080 for ; Tue, 21 Nov 2000 10:39:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 72FE144355; Tue, 21 Nov 2000 09:39:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 80B9944336 for ; Tue, 21 Nov 2000 09:38:47 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eALFb0Y25137; Tue, 21 Nov 2000 09:38:27 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id JAA23565; Tue, 21 Nov 2000 09:37:00 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA05682; Tue, 21 Nov 2000 09:36:59 -0600 (CST) Message-ID: <3A1A33B8.820EA402@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Stuart Wray'" , sip@lists.bell-labs.com Subject: Re: [SIP] URL comparison 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, 21 Nov 2000 09:35:04 +0100 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Hmm. Good question. I honestly can't recall why we said this. I would tend > to agree that: > > sip:user@host:5050;foo=bar > > and > > sip:user@host:5050 > > are not the same. > > Unless someone can come up with a good reason why this should stay, I would > argue that we change this to say "If one of the URLs has a component that is > not present (and has no default value) in the other URL, the URLs are not > equal". This depends on what semantics you apply to that additional component. I would say in this case that these two URLs are equal when considered in the context of a To: or a From:, but unequal in the context of a Request-URI. If you want to make these two cases consistent, I would lean towards considering these two URLs equal in both cases. Otherwise, we should just do a case insensitive string comparison, port included. /sean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 10:58:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27590 for ; Tue, 21 Nov 2000 10:58:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4BC14443EB; Tue, 21 Nov 2000 09:58:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sonusdc3.sonusnet.com (mail.sonusnet.com [63.99.71.102]) by lists.bell-labs.com (Postfix) with ESMTP id 53311443D3 for ; Tue, 21 Nov 2000 09:57:48 -0500 (EST) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 10:57:36 -0500 Message-ID: <9581851D1FB3D21199190090273A744501ED4778@sonusdc3.sonusnet.com> From: "Moloney, Bill" 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] Registration 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, 21 Nov 2000 10:57:33 -0500 Hi - I have a question on registration - Let's say I have client (A) who is configured to register with (B), where B is a proxy server. When A attempts to register with B, B decides to redirect the request to another proxy server C. (If I understand the spec correctly, I believe that I could accomplish this by having B respond to the registration with a 301 Moved Permanently, including a Contact header for C in the response.) The question is this: Does this redirection only impact future registration requests, or does it impact all future requests - such as INVITE? What I am trying to accomplish is to have A direct all of its future requests (not just registration) to the new proxy server (C). Will the redirect that I mention above accomplish this? Thanks, Bill _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 11:04:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28949 for ; Tue, 21 Nov 2000 11:04:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A4754441E; Tue, 21 Nov 2000 10:04:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1C16B443D3 for ; Tue, 21 Nov 2000 10:03:10 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA21220; Tue, 21 Nov 2000 11:02:51 -0500 (EST) Message-ID: <3A1A9CAB.3E6D99BA@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: Jonathan Rosenberg , "'Stuart Wray'" , sip@lists.bell-labs.com Subject: Re: [SIP] URL comparison References: <3A1A33B8.820EA402@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 11:02:51 -0500 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > Jonathan Rosenberg wrote: > > > Hmm. Good question. I honestly can't recall why we said this. I would tend > > to agree that: > > > > sip:user@host:5050;foo=bar > > > > and > > > > sip:user@host:5050 > > > > are not the same. > > > > Unless someone can come up with a good reason why this should stay, I would > > argue that we change this to say "If one of the URLs has a component that is > > not present (and has no default value) in the other URL, the URLs are not > > equal". The problem is that with new parameters, older applications won't know whether the parameter has a default value and what that might be. Thus, you can either - compare well-known parameters (RFC 2543) according to this rule and new parameters according to "ignore" or "unequal if one has it, the other doesn't" rule. This seems less than satisfactory in terms of robustness and simplicity. - Declare missing parameters as unequal to any existing parameter. That doesn't work, due to default values. - Ignore ;-parameters that are only present in one of the URLs being compared. This seems to work for most practical cases. Any examples where this would break things? > > This depends on what semantics you apply to that additional component. I > would say in this case that these two URLs are equal when considered > in the context of a To: or a From:, but unequal in the context of a Request-URI. Having two different comparison routines seems like a recipe for subtle interoperation problems. > > If you want to make these two cases consistent, I would lean towards considering > > these two URLs equal in both cases. That would be my preference. This is in the spirit of "you can add parameters/headers, but don't expect them to matter unless Require'd". > Otherwise, we should just do a case > insensitive > string comparison, port included. > > /sean > > _______________________________________________ > 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 Nov 21 11:18: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 LAA02289 for ; Tue, 21 Nov 2000 11:18:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F8A144428; Tue, 21 Nov 2000 10:18:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id BC88744418 for ; Tue, 21 Nov 2000 10:17:28 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA22067; Tue, 21 Nov 2000 11:17:13 -0500 (EST) Message-ID: <3A1AA00A.1A76C2A5@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Jo Hornsby , Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) References: <20001120204419.A10597@div8.net> <001501c053b5$f7d91940$4e34c3c1@ubiquity.co.uk> <20001121081312.B11312@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: Tue, 21 Nov 2000 11:17:14 -0500 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > Jo Hornsby (jhornsby@ubiquity.net): > > So, UA sends a request, it loops back, they end up putting the same > tag as the To and as the From... You see the problem? Call-leg > endpoint matching is based on: > > call-id,local-uri,local-tag,remote-uri,remote-tag > > And you'll end up with the same key for both. The code gets cleaner > if you always pick random tags. Unfortunately, call-leg-end matching is > very difficult. I'm not sure I follow this logic. If A calls B and B proxies back to A, we get A sending INVITE B From: A To: B The proxy forwards it to A again: INVITE A From: A To: B A can easily tell that it was the origin of the request ("From: A"), so I'm not sure how tags get involved here. In this example, the request doesn't even have To tags. > > As an aside, things would be alot more robust if tags were mandatory. > Ideally, I want to match on: > > call-id,local-tag,remote-tag > > (or for an unconnected call-leg end): > > call-id,local-tag > > Much nicer than this total hack of trying to compare the URIs, > especially when they aren't SIP URIs. Oh well. I doubt that anything but tel: URLs will be useful in this context, so I'm not sure how big a problem this is. I assume by "local-tag" you mean the From tag? -- 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 Nov 21 12:27: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 MAA16056 for ; Tue, 21 Nov 2000 12:27:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E4023443A4; Tue, 21 Nov 2000 11:27:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id CB8F444336 for ; Tue, 21 Nov 2000 11:26:22 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 21 Nov 2000 11:26:00 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: Jo Hornsby , Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) Message-ID: <20001121112600.A11576@div8.net> References: <20001120204419.A10597@div8.net> <001501c053b5$f7d91940$4e34c3c1@ubiquity.co.uk> <20001121081312.B11312@div8.net> <3A1AA00A.1A76C2A5@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A1AA00A.1A76C2A5@cs.columbia.edu>; from hgs@cs.columbia.edu on Tue, Nov 21, 2000 at 11:17:14AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 11:26:00 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > > So, UA sends a request, it loops back, they end up putting the > > same tag as the To and as the From... You see the problem? > > Call-leg endpoint matching is based on: > > > > call-id,local-uri,local-tag,remote-uri,remote-tag > > > > And you'll end up with the same key for both. The code gets > > cleaner if you always pick random tags. Unfortunately, > > call-leg-end matching is very difficult. > > I'm not sure I follow this logic. If A calls B and B proxies back to > A, we get A sending > > INVITE B > From: A > To: B > > The proxy forwards it to A again: > > INVITE A > From: A > To: B > > A can easily tell that it was the origin of the request ("From: A"), > so I'm not sure how tags get involved here. In this example, the > request doesn't even have To tags. What if A and B are the same URI? How do I tell them apart? The user answers the call, I send a 200 OK to the INVITE and then ACK it. Now one of the lines hangs up and I send a BYE: how can I tell which call-leg end the BYE was meant for when it comes back? Was I even able to match that ACK properly? Do I have to special-case calls to myself? That would be really annoying, especially if I'm a gateway. Also note that if you have two UAs which always use the same tags, and there are two calls up between them, you're relying on the call-id for each call to be unique in order to tell them apart. I'm not convinced this will always be the case, as there have been hints that the call-id can be reused to infer special behavior (see my Replaces draft for a cleaner solution). > [...] I assume by "local-tag" you mean the From tag? Well, when I send a request I put the localuri/localtag as the from and the remoteuri/remotetag as the to. When I receive an initial request, I populate the localuri from the to and add a localtag, and the remoteuri/remotetag is taken from the from. I don't like calling them 'To tags' or 'From tags' because it gets confusing. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 12: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 MAA19236 for ; Tue, 21 Nov 2000 12:41:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAA924440A; Tue, 21 Nov 2000 11:40:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id A52E944407 for ; Tue, 21 Nov 2000 11:39:25 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA27069; Tue, 21 Nov 2000 12:39:13 -0500 (EST) Message-ID: <3A1AB341.4C2538BE@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Jo Hornsby , Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) References: <20001120204419.A10597@div8.net> <001501c053b5$f7d91940$4e34c3c1@ubiquity.co.uk> <20001121081312.B11312@div8.net> <3A1AA00A.1A76C2A5@cs.columbia.edu> <20001121112600.A11576@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: Tue, 21 Nov 2000 12:39:13 -0500 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > > I'm not sure I follow this logic. If A calls B and B proxies back to > > A, we get A sending > > > > INVITE B > > From: A > > To: B > > > > The proxy forwards it to A again: > > > > INVITE A > > From: A > > To: B > > > > A can easily tell that it was the origin of the request ("From: A"), > > so I'm not sure how tags get involved here. In this example, the > > request doesn't even have To tags. > > What if A and B are the same URI? How do I tell them apart? Are you saying that A wants to talk to himself? How else would they be the same under normal circumstances? A gateway may want to connect two ports on the same box through the network, but they would have different phone numbers, i.e., different From/To/Request-URIs. I also don't see that if you do normal loop detection, you couldn't handle calls to yourself. Responses and ACKs go to the Via or Contact, respectively. Again, given that in this scenario, tags aren't even involved, I'm at a loss as to why they can matter. > The user > answers the call, I send a 200 OK to the INVITE and then ACK it. Now > one of the lines hangs up and I send a BYE: how can I tell which > call-leg end the BYE was meant for when it comes back? Was I even able > to match that ACK properly? Do I have to special-case calls to myself? Calls to myself are probably a case for the psychologist or a support group :-) > That would be really annoying, especially if I'm a gateway. > > Also note that if you have two UAs which always use the same tags, and > there are two calls up between them, you're relying on the call-id for > each call to be unique in order to tell them apart. I'm not convinced > this will always be the case, as there have been hints that the call-id > can be reused to infer special behavior (see my Replaces draft for a > cleaner solution). If anything, we're probably moving away from overloading the call-id, primarily because you can't control it when somebody "calls in". > > > [...] I assume by "local-tag" you mean the From tag? > > Well, when I send a request I put the localuri/localtag as the from > and the remoteuri/remotetag as the to. When I receive an initial > request, I populate the localuri from the to and add a localtag, and the > remoteuri/remotetag is taken from the from. > > I don't like calling them 'To tags' or 'From tags' because it gets > confusing. I find the designation local/remote tags confusing... -- 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 Nov 21 12:44: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 MAA20095 for ; Tue, 21 Nov 2000 12:44:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92FB34442C; Tue, 21 Nov 2000 11:41:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 1A2114441A for ; Tue, 21 Nov 2000 11:40:33 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 21 Nov 2000 11:40:20 -0600 (CST) From: Billy Biggs To: "Moloney, Bill" Cc: SIP List Subject: Re: [SIP] Registration Question Message-ID: <20001121114020.A11602@div8.net> References: <9581851D1FB3D21199190090273A744501ED4778@sonusdc3.sonusnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <9581851D1FB3D21199190090273A744501ED4778@sonusdc3.sonusnet.com>; from BMoloney@sonusnet.com on Tue, Nov 21, 2000 at 10:57:33AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 11:40:20 -0600 Moloney, Bill (BMoloney@sonusnet.com): > I have a question on registration - > [...] > I believe that I could accomplish this by having B respond to the > registration with a 301 Moved Permanently, including a Contact header > for C in the response.) > > The question is this: Does this redirection only impact future > registration requests, or does it impact all future requests - such as > INVITE? The redirection only impacts the specific registration transaction and (optionally) future registration transactions. Requests such as INVITE go to their destination directly, and have nothing to do with the registration. > What I am trying to accomplish is to have A direct all of its future > requests (not just registration) to the new proxy server (C). Will the > redirect that I mention above accomplish this? This is called an outbound proxy, where even though the message is directed to, say, 'sip:5551212@sip.billybiggs.com', you send the message to 'my.local.proxy.com' which then forwards it on. The outbound proxy is configured directly on the SIP end device, or it can receive it from DHCP. There is no way to signal using REGISTER or whatever that the proxy should be used as an outbound proxy, nor would it make sense to provide such signalling. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 13:05: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 NAA24955 for ; Tue, 21 Nov 2000 13:05:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ED15D44446; Tue, 21 Nov 2000 12:03:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 8DF1744445 for ; Tue, 21 Nov 2000 12:02:55 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 21 Nov 2000 12:02:41 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: Jo Hornsby , Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) Message-ID: <20001121120241.A11719@div8.net> References: <20001120204419.A10597@div8.net> <001501c053b5$f7d91940$4e34c3c1@ubiquity.co.uk> <20001121081312.B11312@div8.net> <3A1AA00A.1A76C2A5@cs.columbia.edu> <20001121112600.A11576@div8.net> <3A1AB341.4C2538BE@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A1AB341.4C2538BE@cs.columbia.edu>; from hgs@cs.columbia.edu on Tue, Nov 21, 2000 at 12:39:13PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 12:02:41 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > > What if A and B are the same URI? How do I tell them apart? > > Are you saying that A wants to talk to himself? How else would they be > the same under normal circumstances? A gateway may want to connect two > ports on the same box through the network, but they would have > different phone numbers, i.e., different From/To/Request-URIs. Yes, A wants to talk to himself. This is a perfectly reasonable diagnostic to see if my registration is active. We do it routinely here. I don't see why it is acceptable to have it fail. I mean, you can telnet to yourself, right? What happens when you SUBSCRIBE to your own presence information so you can watch how you appear online? Those NOTIFYs have to map correctly somewhere. > I also don't see that if you do normal loop detection, you couldn't > handle calls to yourself. Responses and ACKs go to the Via or Contact, > respectively. Well, UAs don't forward requests and therefore don't do loop detection. Sure you might properly handle responses to the single request, but the rest of the requests in that call will fail. > If anything, we're probably moving away from overloading the call-id, > primarily because you can't control it when somebody "calls in". Great. I'd also love to hear what you think of Replaces. http://www.sip-happens.com/replaces/ > > > [...] I assume by "local-tag" you mean the From tag? > > > > Well, when I send a request I put the localuri/localtag as the > > from and the remoteuri/remotetag as the to. When I receive an > > initial request, I populate the localuri from the to and add a > > localtag, and the remoteuri/remotetag is taken from the from. > > > > I don't like calling them 'To tags' or 'From tags' because it gets > > confusing. > > I find the designation local/remote tags confusing... From an implementation point of view it isn't. When you receive a SIP message, you need to first match it to see if its related to any currently active call leg ends. At this point we don't care if its a request or response, so To/From becomes ambiguous. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 13:21: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 NAA28709 for ; Tue, 21 Nov 2000 13:21:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 491F044381; Tue, 21 Nov 2000 12:21:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sonusdc3.sonusnet.com (mail.sonusnet.com [63.99.71.102]) by lists.bell-labs.com (Postfix) with ESMTP id 8FFC144370 for ; Tue, 21 Nov 2000 12:20:19 -0500 (EST) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 13:20:12 -0500 Message-ID: <9581851D1FB3D21199190090273A744501ED4779@sonusdc3.sonusnet.com> From: "Moloney, Bill" To: SIP List Subject: RE: [SIP] Registration 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, 21 Nov 2000 13:20:08 -0500 > The outbound proxy is configured directly on the SIP end device, or it >can receive it from DHCP. There is no way to signal using REGISTER or >whatever that the proxy should be used as an outbound proxy, nor would >it make sense to provide such signalling. I think it does make sense in certain instances. For example, the outbound proxy server is getting overloaded, is going down for scheduled maintainence, or an additional server is being added. Rather than needing to go to each SIP end device, the proxy server would be able to redirect the end device. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 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 SMTP id NAA00644 for ; Tue, 21 Nov 2000 13:29:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F30E344417; Tue, 21 Nov 2000 12:29:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 21CB3443F0 for ; Tue, 21 Nov 2000 12:28:38 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 21 Nov 2000 12:28:28 -0600 (CST) From: Billy Biggs To: "Moloney, Bill" Cc: SIP List Subject: Re: [SIP] Registration Question Message-ID: <20001121122828.A11801@div8.net> References: <9581851D1FB3D21199190090273A744501ED4779@sonusdc3.sonusnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <9581851D1FB3D21199190090273A744501ED4779@sonusdc3.sonusnet.com>; from BMoloney@sonusnet.com on Tue, Nov 21, 2000 at 01:20:08PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 12:28:28 -0600 Moloney, Bill (BMoloney@sonusnet.com): > > The outbound proxy is configured directly on the SIP end device, or > > it can receive it from DHCP. There is no way to signal using > > REGISTER or whatever that the proxy should be used as an outbound > > proxy, nor would it make sense to provide such signalling. > > I think it does make sense in certain instances. For example, the > outbound proxy server is getting overloaded, is going down for > scheduled maintainence, or an additional server is being added. Rather > than needing to go to each SIP end device, the proxy server would be > able to redirect the end device. Your outbound proxy should be a DNS name, not an IP address. So, just change the DNS entry. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 13:35: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 NAA01686 for ; Tue, 21 Nov 2000 13:35:45 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 86A0544432; Tue, 21 Nov 2000 12:32:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 8537344403 for ; Tue, 21 Nov 2000 12:31:33 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 21 Nov 2000 18:31:26 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id TAA18013; Tue, 21 Nov 2000 19:30:01 +0100 (BST) Message-ID: <3A1ABF29.2B01ACC4@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sip List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] More Torture Test Messages Available Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 18:30:01 +0000 Content-Transfer-Encoding: 7bit The proposed new Torture Test messages have been added to the main SIP web site: http://www.cs.columbia.edu/~hgs/sip/bakeoff/testmsg.html The new ones are test21.txt onwards. They should also appear in the new verion of the SIP Message Flows draft shortly. SIP bakeoff entrants are strongly encouraged to run these tests. In particular entrants to advanced scenario testing at bakeoffs will be expected to have passed all torture tests. Comments, corrections etc welcome. 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 Nov 21 13:42:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02795 for ; Tue, 21 Nov 2000 13:42:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 36EE444430; Tue, 21 Nov 2000 12:42:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 5EDC844403 for ; Tue, 21 Nov 2000 12:41:46 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA00886; Tue, 21 Nov 2000 13:41:36 -0500 (EST) Message-ID: <3A1AC1E0.BF722909@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Stuart Wray'" , sip@lists.bell-labs.com Subject: Re: [SIP] URL comparison 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, 21 Nov 2000 13:41:36 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > The A record is only used if there is a port number other > > than 5060 ---- so > > example.com and example.com:5060 both use the SRV record. (Of > > course this may > > result in different machines actually being contacted, but > > that's a different > > matter entirely, not to do with A records). > > This is an error, I believe, resulting in the evolution of this text. We > modified the SRV procedure so that example.com and example.com:5060 were, > indeed, pointing to the same server, but didn't update the text on top which > pointed out the problem. This should already be gone from the -02 draft draft. -- 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 Nov 21 14:08:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06027 for ; Tue, 21 Nov 2000 14:08:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9E8944370; Tue, 21 Nov 2000 13:08:08 -0500 (EST) 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 A7B6F4435F for ; Tue, 21 Nov 2000 13:07:13 -0500 (EST) 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 UAA08530; Tue, 21 Nov 2000 20:06:55 +0100 (MET) Received: by klatt.axis.se with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Nov 2000 20:05:59 +0100 Message-ID: <151F3D2AE9F0D3119E480004ACB8EA3701869309@cluster01.axis.se> From: Peter Kjellerstedt To: "'Neil Deason'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] More Torture Test Messages Available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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, 21 Nov 2000 20:08:49 +0100 In test30.txt if the Expires value is in absolute formate, then a Date header should be supplied too. Otherwise a UA that has no real-time clock will not be able to tell whether this is in the future or past. Actually I think the Expires value should be compared with the Date header if available since the UA on the other end may have an incorrect notion of time... Also, I am still lacking a test for this kind of To/From header: To: sip:pkj@axis.com ;tag=123456789@example.com and make sure the tag does not end up as a URL parameter... //Peter > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: 21 November 2000 19:30 > To: Sip List > Subject: [SIP] More Torture Test Messages Available > > The proposed new Torture Test messages have been added to the > main SIP web site: > > http://www.cs.columbia.edu/~hgs/sip/bakeoff/testmsg.html > > The new ones are test21.txt onwards. They should also appear in > the new verion of the SIP Message Flows draft shortly. > > SIP bakeoff entrants are strongly encouraged to run these tests. > In particular entrants to advanced scenario testing at bakeoffs > will be expected to have passed all torture tests. > > Comments, corrections etc welcome. > 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 Nov 21 15:47: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 PAA25738 for ; Tue, 21 Nov 2000 15:47:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58B4C443FE; Tue, 21 Nov 2000 14:45:18 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 50B6C44403 for ; Tue, 21 Nov 2000 12:37:52 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA22924 for ; Tue, 21 Nov 2000 10:37:49 -0800 (PST) Received: from vovida.com (vvs-lab-nat-171-69-180-242.cisco.com [171.69.180.242]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AAU03685 (AUTH choksi); Tue, 21 Nov 2000 10:37:44 -0800 (PST) Message-ID: <3A1AC0F7.343D12DE@vovida.com> From: Amit Choksi Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Compilation on RedHat 7.0 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 21 Nov 2000 10:37:43 -0800 Content-Transfer-Encoding: 7bit Hi, There are some problems in the compilation of the vovida sipstack and the ua on RedHat 7.0 . Here are a few changes required for the fix 1. If you get a problem with the forward declaration of the class remove it and include the header file 2. If there is a problem with compilation due to the use of vector then include This can occur in a few files like: - SipAccept - SipAcceptEncoding - SipAcceptLanguage to name a few If there are any other issues in compilation please let me know. Thanks Amit Choksi _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 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 SMTP id QAA02498 for ; Tue, 21 Nov 2000 16:16:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A5574441F; Tue, 21 Nov 2000 15:16:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 45FAC443D3 for ; Tue, 21 Nov 2000 15:15:27 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 21 Nov 2000 15:15:18 -0600 (CST) From: Billy Biggs To: SIP List Message-ID: <20001121151518.A11855@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] Deprecate Early Media Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 15:15:18 -0600 1 Deprecate Early Media Listed below are some severe problems with early media. These problems can be solved by connecting (200 OK) before sending media. This creates a billing problem for PSTN gateways which can be solved by either: 1. Separating the billing system from the SIP signalling. Everyone sends detailed CDRs via non-SIP means. 2. Changing the billing contract to charge for ringback and error sessions, just like AT&T cell phones do today. The issues listed below are causing us immediate problems. I focus on PSTN gateways, but the arguments apply to other uses of early media. While this has come up before on the list and been ignored, I feel that early media should be deprecated quickly to avoid a larger mess. Comments appreciated. 2 History of Early Media The early media concept originated with the need for PSTN-style inband altering. The primary reason for not initiating a full SIP session was for billing reasons. As Steve Donovan wrote, "[we] Need [the] ability to have media session setup prior to network-to-network charging." [1] See [2] for more historical context. Apart from that, early media is convenient for gateways as it makes the mapping from Q.931 to SIP more direct. 3 Current Major Problems 3.1 Services Which Use Early Two-Way Audio/Signalling 3.2 Gateways Which Can't Determine Call Failure 3.3 Handling by Forking Proxies which Fork the Call in Parallel 3.4 Handling by Forking Proxies who Sequentially Fork the Call 3.5 Inability to Provide User Recourse 3.6 Difficult Negotiation of Media 3.1 Services Which Use Early Two-Way Audio/Signalling Some PSTN services, usually 800-number services, try and avoid being charged extra by deferring acceptance of a call as long as they can, relying on still receiving DTMF digits over the half-connected call. This was explained by Cliff Harris [3] as follows: "I believe that Q.931 does allow cut-through audio to be set up during the "overlapped dialing" phase of the call. In this scenario, while the caller is still issuing INFO messages containing the dialed digits, the callee sends a PROGRESS message indicating the presence of cut-through audio. The caller sets up an audio path in the backwards direction only. Note that in this situation, the DTMF digits are being sent in the signalling path, not in the media path." Examples: 1-800-CALL-ATT, Verizon Wireless, American Airlines/United Reservations, and many other 1-800 IVR systems. As far as we can tell, there is no way for the gateway to identify this problem. 3.2 Gateways Which Can't Determine Call Failure Based on my experience, some PSTN gateways seem to have problems determining when the call has failed. Henning mentioned this on the list [4]: "This goes back to an earlier, long-ago discussion whether it's better to use 4xx/5xx for announcements, but if I remember right, the conclusion was that this wasn't always feasible since gateways wouldn't be able to distinguish failure announcements from ring tone. (I thought the announcement tri-tone was for stuff like that...)" In this sort of case, UAs which delay sending SDP until the ACK will think the call is still ringing when really a busy signal is being played. 3.3 Handling by Forking Proxies which Fork the Call in Parallel The most obvious problem is when a call forks in parallel to two user agents, each which send early media. As Henning mentioned [4]: "If "early media" is an announcement like "the number you have dialed has been changed. The new number is ...", mixing with ring tone from another destination would be very confusing." The UA can't cancel the branches, and the proxy can't be expected to cancel branches which return SDP. 3.4 Handling by Forking Proxies which Sequentially Fork the Call The problem here is when gateways can't tell that they're sending an early busy signal. The user dials a number, hears a busy signal, and hangs up before the proxy has a chance to time out and switch to the next contact. Even worse, you call through a proxy which first forks to one of these interactive IVRs, asking you for your PIN number. As you're typing it in, the proxy cancels the branch and moves on to the next contact. 3.5 Inability to Provide User Recourse Without using reliable provisional responses, there is no method to allow a user agent to place early media on hold, redirect multiple incoming sessions, or otherwise change its session description short of shutting down the call request. 3.6 Difficult Negotiation of Media A complete system which relies on early media must support reliable provisional responses in order for RTCP to work properly. Other description protocols may have more difficult problems. 4 References [1] http://www.ietf.org/proceedings/99jul/slides/mmusic-sip183-99jul/ [2] http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-183-00.txt [3] http://lists.bell-labs.com/pipermail/sip/2000q3/002352.html [4] http://lists.bell-labs.com/pipermail/sip/2000q3/002297.html -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 16:39: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 QAA07991 for ; Tue, 21 Nov 2000 16:39:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 561AA44412; Tue, 21 Nov 2000 15:39:08 -0500 (EST) 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 3AB57443D3 for ; Tue, 21 Nov 2000 15:12:14 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA19541 for ; Tue, 21 Nov 2000 13:12:05 -0800 (PST) Received: from vovida.com (vvs-lab-nat-171-69-180-242.cisco.com [171.69.180.242]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AAU07978 (AUTH choksi); Tue, 21 Nov 2000 13:12:05 -0800 (PST) Message-ID: <3A1AE524.54CA88B8@vovida.com> From: Amit Choksi Organization: Vovida Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Compilation on RedHat 7.0 References: <3A1AC0F7.343D12DE@vovida.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, 21 Nov 2000 13:12:04 -0800 Content-Transfer-Encoding: 7bit Hi, Please ignore my previous mail about the compilation on redhat 7, I am sorry for that. Thanks Amit Choksi _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 16:46: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 QAA09607 for ; Tue, 21 Nov 2000 16:46:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EDA7D443FB; Tue, 21 Nov 2000 15:46:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 974B1443D3 for ; Tue, 21 Nov 2000 15:45:23 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA24189; Tue, 21 Nov 2000 16:45:11 -0500 (EST) Message-ID: <3A1AECE7.38FA3FCC@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: SIP List Subject: Re: [SIP] Deprecate Early Media References: <20001121151518.A11855@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: Tue, 21 Nov 2000 16:45:11 -0500 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > 1 Deprecate Early Media > > Listed below are some severe problems with early media. These > problems can be solved by connecting (200 OK) before sending media. > This creates a billing problem for PSTN gateways which can be solved > by either: > > 1. Separating the billing system from the SIP signalling. Everyone > sends detailed CDRs via non-SIP means. > > 2. Changing the billing contract to charge for ringback and error > sessions, just like AT&T cell phones do today. > > The issues listed below are causing us immediate problems. I focus on > PSTN gateways, but the arguments apply to other uses of early media. The sooner, the better... However, it should be noted that "early media" has an additional advantage in that it does allow the caller to figure out automatically when to start sending audio. If you had an automatic caller (as is common for various telemarketers or when Al Gore calls you at home before elections), it would not work. Not that I would consider this a major problem, as this appears only when calling IVR systems which presumably don't buy aluminum siding and are too dumb to even create a pregnant chad. For those cases, where the gateway can determine when the call has been connected, sending a re-INVITE to update the sendonly/recvonly designation would seem to be preferable. For billing, I'm not sure that early media is particularly useful except possibly in the case of bridging ISUP islands. The direction indication in SDP would help here, too. For gateways, the gateway presumably knows how long the call into the PSTN was and can thus bill accordingly. I assume gateways are smart enough to recognize the three-tone sequence even if they are not ISUP connected. For IP billing, billing based on resource reservation is the only long-term feasible approach in any event. A related question is whether any SIP implementations actually handle early media. It seems harmless to have in pure IP systems, if it gets never exercised by gateways. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 16:52: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 QAA11098 for ; Tue, 21 Nov 2000 16:52:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D9DA4443A; Tue, 21 Nov 2000 15:52:08 -0500 (EST) 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 2C92F443F1 for ; Tue, 21 Nov 2000 15:51:33 -0500 (EST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 21 Nov 2000 12:47:22 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 21 Nov 2000 12:47:23 -0600 Message-ID: <63E0DAD7784FD21188310000F80824B304B97CD2@zmpkdx02.us.nortel.com> From: "Mo Zonoun" To: "IETF SIP (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C053EB.7799EC10" Subject: [SIP] Changing Codec Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 21 Nov 2000 12:47:15 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C053EB.7799EC10 Content-Type: text/plain; charset="iso-8859-1" How do you change codec in a SIP call without disconnecting the established call? Mo Zonoun ------_=_NextPart_001_01C053EB.7799EC10 Content-Type: text/html; charset="iso-8859-1" Changing Codec

How do you change codec in a SIP call without disconnecting the established call?

Mo Zonoun

------_=_NextPart_001_01C053EB.7799EC10-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 17:03: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 RAA12560 for ; Tue, 21 Nov 2000 17:03:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3474F4443E; Tue, 21 Nov 2000 16:03:10 -0500 (EST) 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 BF80144339 for ; Tue, 21 Nov 2000 16:02:36 -0500 (EST) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 17:04:28 -0500 Message-ID: From: =?iso-8859-1?Q?Pascal_Dor=E9?= To: "'Mo Zonoun'" , "IETF SIP (E-mail)" Subject: RE: [SIP] Changing Codec MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05407.01272220" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 21 Nov 2000 17:04:22 -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_01C05407.01272220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (re)Invite with a new session description =20 Pascal Dor=E9 -----Original Message----- From: Mo Zonoun [mailto:mzonoun@nortelnetworks.com] Sent: Tuesday, November 21, 2000 1:47 PM To: IETF SIP (E-mail) Subject: [SIP] Changing Codec How do you change codec in a SIP call without disconnecting the = established call?=20 Mo Zonoun=20 ------_=_NextPart_001_01C05407.01272220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Changing Codec
(re)Invite with a new session=20 description
 
Pascal=20 Dor=E9
-----Original Message-----
From: Mo Zonoun=20 [mailto:mzonoun@nortelnetworks.com]
Sent: Tuesday, November = 21, 2000=20 1:47 PM
To: IETF SIP (E-mail)
Subject: [SIP] = Changing=20 Codec

How do you change codec in a SIP call without = disconnecting=20 the established call?

Mo Zonoun

------_=_NextPart_001_01C05407.01272220-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 17:21:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14976 for ; Tue, 21 Nov 2000 17:21:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2384844423; Tue, 21 Nov 2000 16:21:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by lists.bell-labs.com (Postfix) with ESMTP id 4F38244339 for ; Tue, 21 Nov 2000 16:20:11 -0500 (EST) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id WAA13379 for ; Tue, 21 Nov 2000 22:20:03 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 21 Nov 2000 22:20:03 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 14:20:02 -0800 Message-ID: <4148FEAAD879D311AC5700A0C969E8902D4880@orsmsx35.jf.intel.com> From: "Gross, Gerhard" 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] I-Ds Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 21 Nov 2000 14:19:58 -0800 Two new I-Ds have been submitted with relevance to the SIP, AAAarch, and RAP working groups. Title : QoS and AAA Usage with SIP Based IP Communications Author(s) : G. Gross, H. Sinnreich, D. Rawlins, S. Thomas Filename : draft-gross-sipaq-00.txt Pages : 23 Date : 20-Nov-00 This document specifies the architecture, protocols and messages for SIP based IP communications between Internet domains in support of QoS and AAA. Detailed message flows and message contents are discussed and specified. AAA requirements including inter-domain and user authorization in mobile and non-mobile environments are addressed. A solution is proposed where session setup and teardown are linked with QoS and AAA signaling using AAA policy servers and clearinghouses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gross-sipaq-00.txt Title : COPS Usage for SIP Author(s) : G. Gross, D. Rawlins, H. Sinnreich, S. Thomas Filename : draft-gross-cops-sip-00.txt Pages : 13 Date : 20-Nov-00 The development of QoS enhanced IP communication requires an infrastructure that supports AAA services. General accounting and settlement on the intra-domain level and inter-domain level are necessary. As part of the solution to these requirements, this document describes a new COPS outsourcing extension for SIP . A description of COPS objects that have special meaning in the SIP environment is provided. The usage of the COPS extension for SIP is given for clients and servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gross-cops-sip-00.txt _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 17:37:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17954 for ; Tue, 21 Nov 2000 17:37:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8219C44445; Tue, 21 Nov 2000 16:37:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 5E52044411 for ; Tue, 21 Nov 2000 16:36:32 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 21 Nov 2000 16:36:21 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: SIP List Subject: Re: [SIP] Deprecate Early Media Message-ID: <20001121163621.A12109@div8.net> References: <20001121151518.A11855@div8.net> <3A1AECE7.38FA3FCC@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A1AECE7.38FA3FCC@cs.columbia.edu>; from hgs@cs.columbia.edu on Tue, Nov 21, 2000 at 04:45:11PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 16:36:21 -0600 Henning, Thanks for your support. :) > A related question is whether any SIP implementations actually handle > early media. You missed my urgency. For the past 11 months I have been unable to use 1-800 IVRs from the only phone on my desk, and get to see my phone say 'Ringing' when I'm clearly hearing a busy signal. Quite frankly, I'm fed up. Yes, phones already receive it, and gateways already send it. > [...] It seems harmless to have in pure IP systems, if it gets never > exercised by gateways. I'm not sure what you mean. Without any gateways, you still have all the forking problems, the need for reliable provisional responses, ... It's still a big mess. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 17:49: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 RAA19460 for ; Tue, 21 Nov 2000 17:49:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2211E44452; Tue, 21 Nov 2000 16:49:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3415F44451 for ; Tue, 21 Nov 2000 16:48:49 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA20413; Tue, 21 Nov 2000 17:51:05 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 17:46:56 -0500 Message-ID: From: Igor Slepchin To: "'Neil Deason'" , Sip List Subject: RE: [SIP] More Torture Test Messages Available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 17:46:55 -0500 Typo in test case 38: Contact: ;user=phone Here, user=phone is actually a header parameter, opposite to what the description says. You probably want the closing angle bracket after the parameter. Test case 41: I'd argue that this message should be rejected with a 400. Section 4.1 lists SIP version as a literal and doesn't say anything about ignoring leading zeros. As an example of why rejecting it is a good idea, consider version numbers like 2.1 and 2.01 - they are unlikely to refer to the same version. Interestingly, Appendix C mentions that literals are case-insensitive. I think it is reasonable to explicitly state that the SIP-Version is case-sensitive. This would make Via definition consistent: it currently defines protocol-name as either literal "SIP" (case-insensitive) or token (case-sensitive). Thank you, Igor Slepchin > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Tuesday, November 21, 2000 1:30 PM > To: Sip List > Subject: [SIP] More Torture Test Messages Available > > > The proposed new Torture Test messages have been added to the > main SIP web site: > > http://www.cs.columbia.edu/~hgs/sip/bakeoff/testmsg.html > > The new ones are test21.txt onwards. They should also appear in > the new verion of the SIP Message Flows draft shortly. > > SIP bakeoff entrants are strongly encouraged to run these tests. > In particular entrants to advanced scenario testing at bakeoffs > will be expected to have passed all torture tests. > > Comments, corrections etc welcome. > 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 Tue Nov 21 21:00: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 VAA14702 for ; Tue, 21 Nov 2000 21:00:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 90A244442F; Tue, 21 Nov 2000 19:29:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06s.us.nortel.com (unknown [47.140.48.50]) by lists.bell-labs.com (Postfix) with ESMTP id 04FDB4442E for ; Tue, 21 Nov 2000 19:28:01 -0500 (EST) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 21 Nov 2000 11:23:43 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 21 Nov 2000 10:37:19 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E80517B9EE@zwdld001.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C053D0.E91C8FC0" X-Orig: Subject: [SIP] New I-D: draft-hamer-sip-session-auth-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 10:37:09 -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_01C053D0.E91C8FC0 Content-Type: text/plain; charset="iso-8859-1" Folks, My colleague and I have submitted the following draft to the SIP WG and would appreciate any comments or questions prior to the next meeting in San Diego. Cheers, Louis-Nicolas Hamer -----Original Message----- From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] Sent: Monday, November 13, 2000 6:40 AM To: IETF-Announce Subject: I-D ACTION:draft-hamer-sip-session-auth-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session setup with media authorization Author(s) : L. Hamer, B. Gage Filename : draft-hamer-sip-session-auth-00.txt Pages : 23 Date : 10-Nov-00 Current proposals dealing with authorization of media streams for multimedia services like IP telephony and video assume a pre- established relationship between elements of the network (e.g. session managers, edge routers, policy servers and end hosts). In some environments, however, such pre-established relationships may not exist either due to the complexity of creating these associations a priori (e.g. in a network with many elements), or due to the different business entities involved (e.g. service provider and access provider), or due to the dynamic nature of these associations (e.g. in a mobile environment). In this document, we describe scenarios where there is no pre- established relationship between entities and describe mechanisms for exchanging information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the session and bearer control planes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hamer-sip-session-auth-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hamer-sip-session-auth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hamer-sip-session-auth-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. ------_=_NextPart_001_01C053D0.E91C8FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New I-D: draft-hamer-sip-session-auth-00.txt

Folks,

My colleague and I have submitted the = following draft to the SIP WG and would appreciate any comments
or questions prior to the next = meeting in San Diego.

Cheers,
Louis-Nicolas Hamer


-----Original Message-----
From:   Internet-Drafts@ietf.org = [SMTP:Internet-Drafts@ietf.org]
Sent:   Monday, November 13, 2000 6:40 AM
To:     IETF-Announce
Subject:       = I-D = ACTION:draft-hamer-sip-session-auth-00.txt

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


        Title   =         : Session setup with media = authorization
        Author(s)       : L. = Hamer, B. Gage
        Filename        : = draft-hamer-sip-session-auth-00.txt
        Pages   =         : 23
        Date    =         : 10-Nov-00
       =20
Current proposals dealing with = authorization of media streams for
multimedia services like IP telephony = and video assume a pre-
established relationship between = elements of the network (e.g.
session managers, edge routers, = policy servers and end hosts). In
some environments, however, such = pre-established relationships may
not exist either due to the = complexity of creating these
associations a priori (e.g. in a = network with many elements), or due
to the different business entities = involved (e.g. service provider
and access provider), or due to the = dynamic nature of these
associations (e.g. in a mobile = environment).
In this document, we describe = scenarios where there is no pre-
established relationship between = entities and describe mechanisms
for exchanging information between = network elements in order to
authorize the use of resources for a = service and to co-ordinate
actions between the session and = bearer control planes.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-hamer-sip-se= ssion-auth-00.txt

Internet-Drafts are also available by = anonymous FTP. Login with the username
"anonymous" and a password = of your e-mail address. After logging in,
type "cd internet-drafts" = and then
        "get = draft-hamer-sip-session-auth-00.txt".

A list of Internet-Drafts directories = can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained = by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-hamer-sip-session-auth-00.txt".
       =20
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.


------_=_NextPart_001_01C053D0.E91C8FC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 21:03: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 VAA15083 for ; Tue, 21 Nov 2000 21:03:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C73264435F; Tue, 21 Nov 2000 18:44:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id A94E04433B for ; Tue, 21 Nov 2000 18:43:17 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 21 Nov 2000 18:43:06 -0600 (CST) From: Billy Biggs To: =?iso-8859-1?Q?Pascal_Dor=E9?= Cc: Mo Zonoun , SIP List Subject: Re: [SIP] Changing Codec Message-ID: <20001121184306.A12151@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.0.1i In-Reply-To: ; from pdore@mediatrix.com on Tue, Nov 21, 2000 at 05:04:22PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 18:43:06 -0600 Content-Transfer-Encoding: 8bit Pascal Doré (pdore@mediatrix.com): > > How do you change codec in a SIP call without disconnecting the > > established call? > > (re)Invite with a new session description Actually, it depends on if you are talking about send codec or receive codec. If you want to change the codec you are sending, then as long as the other end indicated support, you can change any time you like. For example, if I send you SDP that says: m=audio 8552 RTP/AVP 0 1 2 Then you can freely switch between sending audio using codec 0, 1 or 2. If you're feeling cruel, you can use a different codec for every packet. If you want to change which codec you are receiving from the far end, the best you can do is offer a different set of choices using a re-INVITE. So, first maybe you send: m=audio 8552 RTP/AVP 0 1 2 And the far end is sending you codec 1, but you only want to receive codec 0, then you can always re-INVITE with: m=audio 8552 RTP/AVP 0 And force it to use either codec 0 or nothing. Be prepared though that if the remote end can't send codec 0, it might tear down the call (or at best audio won't flow). -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 21:12: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 VAA16123 for ; Tue, 21 Nov 2000 21:12:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 247F14440E; Tue, 21 Nov 2000 19:25:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.au.ac.th (unknown [202.6.101.20]) by lists.bell-labs.com (Postfix) with ESMTP id 08A3144340 for ; Tue, 21 Nov 2000 19:24:01 -0500 (EST) Received: from pcpop (pc-pop.aunet.au.ac.th [168.120.21.4]) by mail.au.ac.th (Postfix) with SMTP id 7EE9B4B83 for ; Wed, 22 Nov 2000 08:21:54 +0700 (GMT) From: "Voravit H." To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C0545D.DA6C5B80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] About SDP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 08:26:03 +0700 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C0545D.DA6C5B80 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: base64 RGVhciBhbGwNCg0KCUlzIHRoZXJlIGFueSBmcmVlIFNEUCBBUEkgZm9yIGVkdWNhdGlvbiBwdXJw b3NlIG91dCB0aGVyZT8NCglJIGFtIG5vdyB0cnlpbmcgdG8gaW1wbGVtZW50IFNJUCBidXQgSSBz dHVjayBvbiBTRFAgY29udGVudC4NCg0KTXIuIFZvcmF2aXQgSC4NCg== ------=_NextPart_000_0000_01C0545D.DA6C5B80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMBAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAagMAAAAAAABtAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHCwAVAA4AIQAAAAIAKAEB A5AGAEgFAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAACgAAAEFib3V0IFNEUAAAAAIBcQABAAAAFgAAAAHAU41LgHDDZey/ixHUtyQAgEjjz2sAAAIB HQwBAAAAEgAAAFNNVFA6UE9QQEFVLkFDLlRIAAAACwABDgAAAABAAAYOAN44Ro1TwAECAQoOAQAA ABgAAAAAAAAAaw5CRCz/0xG3JACASOPPa8KAAAALAB8OAQAAAAIBCRABAAAADQEAAAkBAABEAQAA TFpGdRs9nVQDAAoAcmNwZzg3NAMA+AtgbmcxMDU0TwH3AqQDYwIAY2gKwHNIZXQyEUAgQQ8Qc6EA cGFVUEMCgH0KgVJ2CJB3awuAZA5AdU5jAFALAw70MzMLpDP5EWBEZQrBB0AJUAqxCoSTCoEBkSBJ BCB0aASQ4mUVAG55IANQCeAGAOREUBFwUEkXEAWxCYCREyBhdGkCICBwCHB0cG8RECAIYAVAFoM/ QxWqFQBtIG5vB+B0lHJ5C4BnFnBvIAdwXQtQZQeAAjAGAEkXkGLTGWEX0HN0EyBrGUADoC8XcgWg AjAcMS4VSk1yaC4gVgWwYRKABUBILx5QDvYVRBJBACEwAAAACwABgAggBgAAAAAAwAAAAAAAAEYA AAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAA AAAAAABGAAAAAFKFAABpeQEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4w AB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAuACCAGAAAAAADAAAAA AAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAMgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAAB AAAAAAAAAAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwA6gAggBgAAAAAAwAAAAAAA AEYAAAAADoUAAAAAAAADADyACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAPYAIIAYAAAAA AMAAAAAAAABGAAAAABiFAAAAAAAACwBUgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAFWA CCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAIB+A8BAAAAEAAAAGsOQkQs/9MRtyQAgEjjz2sC AfoPAQAAABAAAABrDkJELP/TEbckAIBI489rAgH7DwEAAACCAAAAAAAAADihuxAF5RAaobsIACsq VsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcV0lORE9XU1xMb2NhbCBT ZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0AAAA AwD+DwUAAAADAA00/TcAAAIBfwABAAAALAAAADxOREJCTEhDRUdMSU9BS0tIT0RKRU1FQ0xDQUFB LnBvcEBhdS5hYy50aD4AAwAGEDDH2McDAAcQcAAAAAMAEBAAAAAAAwAREAEAAAAeAAgQAQAAAGUA AABERUFSQUxMSVNUSEVSRUFOWUZSRUVTRFBBUElGT1JFRFVDQVRJT05QVVJQT1NFT1VUVEhFUkU/ SUFNTk9XVFJZSU5HVE9JTVBMRU1FTlRTSVBCVVRJU1RVQ0tPTlNEUENPTlRFAAAAAJP6 ------=_NextPart_000_0000_01C0545D.DA6C5B80-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 21 21:50: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 VAA21484 for ; Tue, 21 Nov 2000 21:50:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2153144425; Tue, 21 Nov 2000 20:49:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8279344406 for ; Tue, 21 Nov 2000 20:48:07 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA10733; Tue, 21 Nov 2000 21:47:55 -0500 (EST) Message-ID: <3A1B33DB.3D30D366@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Lars Berggren Cc: Billy Biggs , Jo Hornsby , Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 21:47:55 -0500 Content-Transfer-Encoding: 7bit Lars Berggren wrote: > > > I agree with Billy and would suggest that tags should be unique to each > instance of a user agent and maybe even unique to a call. They are already unique to each instance of a user agent, as described. If you have two SIP UAs running on the same host (on different ports, presumably), they will have different tags. The same "brand" of UA on different hosts will have different UAs. If it were useful, having different tags for From and To from the same UA may even be useful, although it would be nice to have a scenario for that. I have yet to understand why re-using the same tag across restarts hurts anything. After all, you're not worried about confusing messages when a SIP UA is revived. Maybe we should look at the self-call in a bit more detail (I'm assuming From tags here): INVITE self To: self From: self;tag=T Via: self This will be "filed" under to=self/*, from=self/T. Any incoming request will have their From/To reversed and mapped. As long as the two tags The response will be 200 OK To: self;tag=T From: self;tag=T This will map to the same entry. A BYE will then use BYE self To: self;tag=T From: self;tag=T The major problem occurs probably not so much because of mapping, but rather since this is treated as a re-INVITE while the first one is still pending. -- 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 Nov 21 22:08:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23596 for ; Tue, 21 Nov 2000 22:08:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 979CA4444F; Tue, 21 Nov 2000 21:08:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 025D544436 for ; Tue, 21 Nov 2000 21:07:40 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA11656; Tue, 21 Nov 2000 22:07:31 -0500 (EST) Message-ID: <3A1B3873.58E8E633@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: "'Neil Deason'" , Sip List Subject: Re: [SIP] More Torture Test Messages Available 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, 21 Nov 2000 22:07:31 -0500 Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > Typo in test case 38: > > Contact: ;user=phone > > Here, user=phone is actually a header parameter, opposite to what the > description says. You probably want the closing angle bracket after the > parameter. Fixed. > > Test case 41: > > I'd argue that this message should be rejected with a 400. Section 4.1 lists > SIP version as a literal and doesn't say anything about ignoring leading > zeros. As an example of why rejecting it is a good idea, consider version > numbers like 2.1 and 2.01 - they are unlikely to refer to the same version. Version numbers are not real numbers. Typically, you have 2.1,2.2,...,2.9,2.10,2.11, which isn't exactly numerical progression. Well, the zero issue isn't quite as clear-cut, as RFC 2616 says: The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent. I also just tried GET / http/1.1 Host: www.cs.columbia.edu (which is a standard Apache server) and this works fine. > > Interestingly, Appendix C mentions that literals are case-insensitive. I > think it is reasonable to explicitly state that the SIP-Version is > case-sensitive. This would make Via definition consistent: it currently > defines protocol-name as either literal "SIP" (case-insensitive) or token > (case-sensitive). Wait, if protocol is defined as, say protocol-token = "FOO" | "BAR" it would be CI. This is consistent with the use in RFC 2616, where all tokens are defined as CI (such as character-set, content-coding, transfer-coding, type, subtype, etc. -- 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 Nov 21 23:42: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 XAA08260 for ; Tue, 21 Nov 2000 23:42:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6CCDE44342; Tue, 21 Nov 2000 21:43:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id F1B844433B for ; Tue, 21 Nov 2000 21:42:03 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 21 Nov 2000 21:40:09 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: Lars Berggren , Jo Hornsby , Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) Message-ID: <20001121214009.A12322@div8.net> References: <3A1B33DB.3D30D366@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A1B33DB.3D30D366@cs.columbia.edu>; from hgs@cs.columbia.edu on Tue, Nov 21, 2000 at 09:47:55PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 21:40:09 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > I have yet to understand why re-using the same tag across restarts > hurts anything. After all, you're not worried about confusing messages > when a SIP UA is revived. > > Maybe we should look at the self-call in a bit more detail > [...] > The major problem occurs probably not so much because of mapping, but > rather since this is treated as a re-INVITE while the first one is > still pending. Sorry I don't quite understand what you mean. It looks like your email got a bit truncated. To help, I'm going to describe a scenario where a UA calls itself, and that UA always uses a local tag (To or From) of 7. Hopefully this will help to clarify the problem. I decide to call myself. I create a call-leg struct to represent it. Let's call it "Line 1". I send out the initial INVITE: [From Line 1] INVITE sip:me@proxy Via: SIP/2.0/UDP my.ip To: From: ;tag=7 Call-ID: 5 This eventually loops back to me. Now I see coming in: INVITE sip:me@proxy Via: SIP/2.0/UDP some.ip To: From: ;tag=7 Call-ID: 5 I check and see there is no To-tag, so this is a new incoming call. I create a call struct to represent it, called "Line 2". Line 2 now begins ringing. I respond with a 180 and the user switches lines and answers the incoming call: [From Line 2] SIP/2.0 200 OK Via: SIP/2.0/UDP some.ip To: ;tag=7 From: ;tag=7 Call-ID: 5 When I receive this response, I find the related pending transaction. Arguably, I could first find which call-leg it is destined to (and immediately have a problem), but say that I do transaction mapping first so we don't break yet. I match the OK and send an ACK: [From Line 1] ACK sip:me@contactaddr Via: SIP/2.0/UDP my.ip To: ;tag=7 From: ;tag=7 Call-ID: 5 At which point the other pending transaction also correctly matches this ACK to it. Now, on Line 2, I decide to hang up. I've had enough of talking to myself. So, I send a BYE: [From Line 2] BYE sip:me@contact.addr Via: SIP/2.0/UDP my.ip To: ;tag=7 From: ;tag=7 Call-ID: 5 I now see this incoming BYE: BYE sip:me@contact.addr Via: SIP/2.0/UDP some.ip To: ;tag=7 From: ;tag=7 Call-ID: 5 Which one of the calls is it for? Is it for the line which originated the call, or the line which received the call? Using unique tags per call avoids any confusion even in this case, and also protects the UA against clients which always use the same tag and happen to make two calls with the same Call-ID. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 00:28: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 AAA14158 for ; Wed, 22 Nov 2000 00:28:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9AA7D443F3; Tue, 21 Nov 2000 23:28:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id DFAE944339 for ; Tue, 21 Nov 2000 23:27:03 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 21:26:58 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Neil Deason'" , Sip List Subject: RE: [SIP] More Torture Test Messages Available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 21 Nov 2000 21:26:57 -0800 The colon in the user part of Test 36 (the long telephone subscriber) needs to be quoted. Perhaps you could also put a similar long telephone-subscriber URL in the Contact - this would test whether the URL was correctly reproduced if the call is accepted. Cheers, Robert. > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Wednesday, November 22, 2000 2:30 AM > To: Sip List > Subject: [SIP] More Torture Test Messages Available > > > The proposed new Torture Test messages have been added to the > main SIP web site: > > http://www.cs.columbia.edu/~hgs/sip/bakeoff/testmsg.html > > The new ones are test21.txt onwards. They should also appear in > the new verion of the SIP Message Flows draft shortly. > > SIP bakeoff entrants are strongly encouraged to run these tests. > In particular entrants to advanced scenario testing at bakeoffs > will be expected to have passed all torture tests. > > Comments, corrections etc welcome. > 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 Wed Nov 22 03:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05280 for ; Wed, 22 Nov 2000 03:55:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 323B14442B; Wed, 22 Nov 2000 02:55:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 274664433E for ; Wed, 22 Nov 2000 02:54:54 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA22956; Wed, 22 Nov 2000 03:57:06 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 03:52:56 -0500 Message-ID: From: Jonathan Rosenberg To: "'Hisham Khartabil'" , sip@lists.bell-labs.com Subject: RE: [SIP] Contact header is a 200 response to SUBSCRIBE for IMPP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 03:52:55 -0500 > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > Sent: Tuesday, November 21, 2000 8:44 AM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] Contact header is a 200 response to SUBSCRIBE for > IMPP > > > Hi, > I'm posting the following again since there was no reply the > first time > around > > Regards, > Hisham Khartabil > Hotsip Finland > www.hotsip.com > > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On > Behalf Of Hisham Khartabil > Sent: Thursday, 9 November 2000 11:41 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Contact header is a 200 response to SUBSCRIBE for IMPP > > Section 4.2 of the presence draft has the following examples: > > SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0 > Via: SIP/2.0/UDP userpc.example.com > To: sip:jdrosen@dynamicsoft.com > From: sip:user@example.com > Contact: sip:user@userpc.example.com > Call-ID: knsd08alas9dy@3.4.5.6 > CSeq: 1 SUBSCRIBE > Content-Length: 0 > > > > SIP/2.0 200 OK > Via: SIP/2.0/UDP presenceserver.dynamicsoft.com > Via: SIP/2.0/UDP userpc.example.com > To: sip:jdrosen@dynamicsoft.com > From: sip:user@example.com > Contact: sip:user@userpc.example.com > Record-Route: > sip:jdrosen@example.com;maddr=presenceserver.dynamicsoft.com > Expires: 3600 > Call-ID: knsd08alas9dy@3.4.5.6 > CSeq: 1 SUBSCRIBE > Content-Type: application/xpidf+xml > Content-Length: 287 > > > PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd"> > > > >
> >
> > > > > > Then, it goes on to say: > "Notice that the response has mirrored many fields from the > request,including the To, From, Call-ID, CSeq, and Via > headers. The PA has > also added a Contact header, providing an address where it > can be reached. > The response also contains a Record-Route header. This header > was presumably > inserted by the proxy (the address in the maddr header is > that of a presence > server acting as a proxy), and is reflected in the 200 OK > response. The > response also contains a presence document for the > presentity, and a Contact > header. The Contact headers in a response to SUBSCRIBE list > all the current > addresses which have been subscribed." > > The example shows that the Contact header in the response > does actually list > the current address which has been subscribed > (user@userpc.example.com). > But I fail to see where the Contact header that the PA added > providing an > address where it can be reached. Err, we have inconsistent text here on what the meaning of Contact header is in the 200 response. The problems relate to the dual usage of SUBSCRIBE to have INVITE-like record-routing semantics, and REGISTER like informational semantics. There are two choices: 1. We go all the way to INVITE like semantics, so that the Contact in the response is the PA address. The Contact address in the SUBSCRIBE itself is therefore not mirrored. 2. We maintain a hybrid, and instead of having the PA insert a Contact into the response, the PA itself "record-routes", even though its not a proxy. I'd prefer (1) at this point, especially now that we have dropped the multiple Contacts in SUBSCRIBE. -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 Nov 22 04:27:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08796 for ; Wed, 22 Nov 2000 04:27:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0143544441; Wed, 22 Nov 2000 03:27:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 424B94433E for ; Wed, 22 Nov 2000 03:26:57 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XKW3X1CB; Wed, 22 Nov 2000 10:24:35 +0100 From: "Hisham Khartabil" To: "Jonathan Rosenberg" , Subject: RE: [SIP] Contact header is a 200 response to SUBSCRIBE for IMPP 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 11:28:05 +0200 Content-Transfer-Encoding: 7bit I wasn't aware the "multiple contacts" has been dropped from SUBSCRIBE. Why was the dropped? Even then, why wouldn't the 200 responses contain the contacts of the individual subscriptions (registration like)? I agree with option 1 though. Knowing where to directly contact the PA is much more useful than getting a response with contacts you subscribed to (they should be stored somewhere on the client anyway) Hisham -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Wednesday, 22 November 2000 10:53 AM To: 'Hisham Khartabil'; sip@lists.bell-labs.com Subject: RE: [SIP] Contact header is a 200 response to SUBSCRIBE for IMPP > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > Sent: Tuesday, November 21, 2000 8:44 AM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] Contact header is a 200 response to SUBSCRIBE for > IMPP > > > Hi, > I'm posting the following again since there was no reply the > first time > around > > Regards, > Hisham Khartabil > Hotsip Finland > www.hotsip.com > > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On > Behalf Of Hisham Khartabil > Sent: Thursday, 9 November 2000 11:41 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Contact header is a 200 response to SUBSCRIBE for IMPP > > Section 4.2 of the presence draft has the following examples: > > SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0 > Via: SIP/2.0/UDP userpc.example.com > To: sip:jdrosen@dynamicsoft.com > From: sip:user@example.com > Contact: sip:user@userpc.example.com > Call-ID: knsd08alas9dy@3.4.5.6 > CSeq: 1 SUBSCRIBE > Content-Length: 0 > > > > SIP/2.0 200 OK > Via: SIP/2.0/UDP presenceserver.dynamicsoft.com > Via: SIP/2.0/UDP userpc.example.com > To: sip:jdrosen@dynamicsoft.com > From: sip:user@example.com > Contact: sip:user@userpc.example.com > Record-Route: > sip:jdrosen@example.com;maddr=presenceserver.dynamicsoft.com > Expires: 3600 > Call-ID: knsd08alas9dy@3.4.5.6 > CSeq: 1 SUBSCRIBE > Content-Type: application/xpidf+xml > Content-Length: 287 > > > PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd"> > > > >
> >
> > > > > > Then, it goes on to say: > "Notice that the response has mirrored many fields from the > request,including the To, From, Call-ID, CSeq, and Via > headers. The PA has > also added a Contact header, providing an address where it > can be reached. > The response also contains a Record-Route header. This header > was presumably > inserted by the proxy (the address in the maddr header is > that of a presence > server acting as a proxy), and is reflected in the 200 OK > response. The > response also contains a presence document for the > presentity, and a Contact > header. The Contact headers in a response to SUBSCRIBE list > all the current > addresses which have been subscribed." > > The example shows that the Contact header in the response > does actually list > the current address which has been subscribed > (user@userpc.example.com). > But I fail to see where the Contact header that the PA added > providing an > address where it can be reached. Err, we have inconsistent text here on what the meaning of Contact header is in the 200 response. The problems relate to the dual usage of SUBSCRIBE to have INVITE-like record-routing semantics, and REGISTER like informational semantics. There are two choices: 1. We go all the way to INVITE like semantics, so that the Contact in the response is the PA address. The Contact address in the SUBSCRIBE itself is therefore not mirrored. 2. We maintain a hybrid, and instead of having the PA insert a Contact into the response, the PA itself "record-routes", even though its not a proxy. I'd prefer (1) at this point, especially now that we have dropped the multiple Contacts in SUBSCRIBE. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 04:31:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09228 for ; Wed, 22 Nov 2000 04:31:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F16724444E; Wed, 22 Nov 2000 03:31:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id 19A384444D for ; Wed, 22 Nov 2000 03:30:13 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 22 Nov 2000 09:29:20 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id JAA03814; Wed, 22 Nov 2000 09:04:19 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025699F.0031CC5E ; Wed, 22 Nov 2000 09:03:55 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Stuart Wray" To: "Henning G. Schulzrinne" Cc: Sean Olson , Jonathan Rosenberg , sip@lists.bell-labs.com Message-ID: <8025699F.0031C9EA.00@marconicomms.com> Subject: Re: [SIP] URL comparison 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, 22 Nov 2000 09:03:48 +0000 Henning Schulzrinne wrote: > The problem is that with new parameters, older applications won't know > whether the parameter has a default value and what that might be. I don't think this problem has a neat solution. I think what is really wanted is that URLs which are semantically equivalent should compare as equal. But if a new parameter changes the semantics how can older applications ever make the right judgement? > Thus, > you can either > > - compare well-known parameters (RFC 2543) according to this rule and > new parameters according to "ignore" or "unequal if one has it, the > other doesn't" rule. This seems less than satisfactory in terms of > robustness and simplicity. > > - Declare missing parameters as unequal to any existing parameter. That > doesn't work, due to default values. > > - Ignore ;-parameters that are only present in one of the URLs being > compared. This seems to work for most practical cases. Any examples > where this would break things? In this last case do you really mean to ignore the port number if it is not present in both URLs? Stuart Wray _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 04:33: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 EAA09496 for ; Wed, 22 Nov 2000 04:33:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2796144457; Wed, 22 Nov 2000 03:32:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E99B24444D for ; Wed, 22 Nov 2000 03:31:35 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA23050; Wed, 22 Nov 2000 04:33:44 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 04:29:34 -0500 Message-ID: From: Jonathan Rosenberg To: "'Hisham Khartabil'" , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: RE: [SIP] Contact header is a 200 response to SUBSCRIBE for IMPP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 04:29:33 -0500 > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > Sent: Wednesday, November 22, 2000 4:28 AM > To: Jonathan Rosenberg; sip@lists.bell-labs.com > Subject: RE: [SIP] Contact header is a 200 response to SUBSCRIBE for > IMPP > > > I wasn't aware the "multiple contacts" has been dropped from > SUBSCRIBE. That thread may have been on sip-events. > Why > was the dropped? It doesn't work with record-routing. > Even then, why wouldn't the 200 responses contain the contacts of the > individual subscriptions (registration like)? Because SUBSCRIBE is more like INVITE than REGISTER. -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 Nov 22 04:43:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10590 for ; Wed, 22 Nov 2000 04:43:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 18BBE4445C; Wed, 22 Nov 2000 03:43:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 00B694445B for ; Wed, 22 Nov 2000 03:42:20 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA23107; Wed, 22 Nov 2000 04:44:33 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 04:40:23 -0500 Message-ID: From: Jonathan Rosenberg To: "'David Shrader'" , SIP List Subject: RE: [SIP] Contact: header in re-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: Wed, 22 Nov 2000 04:40:23 -0500 Contact should be sent in every INVITE. Due to crash and restart, what is a re-INVITE for one user is a new INVITE for another. If the Contact is different, yes, it should be updated in the Route set. This is needed for certain proposed mobility applications, and I suspect has some other very useful properties ala third party call control. -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: David Shrader [mailto:dshrader@master-consultant.com] > Sent: Thursday, November 09, 2000 11:17 AM > To: SIP List > Subject: [SIP] Contact: header in re-INVITE > > > Table 4 indicates that the Contact: header is mandatory "m" > in the INVITE > request. Is this necessary for a re-INVITE message when the > two endpoints > have already established communication. > > I think this is similar to the Record-Route mechanism in > which the route is > recorded once and applies to subsequent requests on the same > call leg. For > that matter, if the Contact were to change. Do we change the > Record-Route/Route as well? > > David > > ---------------------------- > David Shrader > Master Consultant, Inc. > dshrader@master-consultant.com > http://www.EyeForTheFuture.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 05:23: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 FAA14915 for ; Wed, 22 Nov 2000 05:23:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 882174445B; Wed, 22 Nov 2000 04:23:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B672A44456 for ; Wed, 22 Nov 2000 04:22:27 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA23246; Wed, 22 Nov 2000 05:24:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 05:20:35 -0500 Message-ID: From: Jonathan Rosenberg To: "'Robin Escolme'" , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 05:20:35 -0500 Finally getting around to this.... sorry for the delay: > -----Original Message----- > From: Robin Escolme [mailto:Robin.Escolme@marconi.com] > Sent: Thursday, November 02, 2000 10:45 AM > To: Jonathan Rosenberg > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt > > > > > Hi, > > Some comments and questions : > > Section 5.2, CASE I - UAC supports session timers. The > text states "In this > case the proxy remembers that it inserted a > Session-Expires header into the > request and that the UAC supported sesion timer". The > proxy may not have > inserted a Session-Expires header - it would only have > done so if the there > wasn't one in the request from the UAC. I rewrote the text for CASE I. There are actually two sub-cases. One is when the proxy is the one closest to the UAS (in which case it inserts Session-TImer and Require into the response), and the other case is for all other proxies. For those proxies, this case is indistinguishable from CASE IV. > CASE II - UAC Doesn't support, UAS doesn't support. There > is, presumably, > nothing to stop the proxy, if its policy dictates, from > running a local > session timer, the expiration of which would result in it > de-allocating any > resources - and in particular, closing any pin-holes > opened across a > firewall, with no indication at all to the end points. > Whilst this isn't very > nice for the end points, since their RTP packets would > suddenly cease, the > proxy is trying to protect it's network resources from > unreliable end-points. > The session timer used be longer that normal, given there > is no opportunity > to refresh. Alternatively, cannot the proxy issue a > re-INVITE to each UA, > using the same SDP used orginally? No, it cannot. Proxies do not initiate requests except for ACK and CANCEL. If the proxy wants to run a local timer on its own, well, thats its own choice. There are no protocol implications of that, and it has nothing to do with this session timer specification. Thus, I see no need to discuss it here. > Section 6, Para 2 states "If the the UAS places a > Session-Expires header into > the response, and the request contained a Supported header > with the value > "timer",.......". This implies that the UAS may place a > Session-Espires > header into the response when the request did not contain > a Supported header > with the value "timer". However, the table further down > says that if the > request contained neither a Supported header with the > value "timer", nor a > Session-Expires header, there there will be no timers. > Surely, if the UAS > supports session timers it can place a Session-Expires > header in the > response, so that it indicates to proxies that it is > running a session timer. > If this is the case, then the behavoir in the foirst row > of this table should > indicate that the UAS MAY add a session-Expires header to > the response. This > then equates to CASE III in section 5.2. Yes, you are correct. I have updated the table. > Section 6, last para suggests that a 200 OK in response to > a re-INVITE may > not contain a Session-Expire header. How can this be, > unless a proxy or the > UAC has removed it, which I thought was not allowed? No; the case is when the proxies change their mind and decide that they no longer want session timer. In this case, the re-invite had a supported header, but no session-expires. No proxies were interested, so none inserted session-expires. UAS doesn't support, so the response has no session-expires, no Require. I added a sentence explaining when this happens. > Section 8.5 - call flow for re-INVITE. The Calling UA send > the INVITE to the > SPS with a Session-Expires header. The note against the > next message, INVITE > from SPS to Called UA says the SPS adds the S-E header, > but it was already > there. Copy-paste error. Fixed. > General - ther terms UAC and UAS I have taken to be > synonymous with Calling > UAC and Called UAC, respectively. The document makes use > of both terms at > varying times. Are these terms interchangeable or is there > some implied > difference. THe roles of UAC and UAS are on a transaction by transaction basis. The initiator of a request is the UAS. Recipient is UAS. Caller and called party reflect the initial invite request. I believe the terms are used consistent with this definition. This definition is the one present in rfc2543. > Section 9 of RFC2543bis02 lists abbreviated forms for > common header fields. > The session timer feature is valuable and may be insisted > upon by many > networks, bringing the Session Expires header into common > use. You should > consider an abbreviated form. Good idea. I've taken 'x', for eXpires. Thanks for your comments, 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 Nov 22 05:30:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15841 for ; Wed, 22 Nov 2000 05:30:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3170A4446B; Wed, 22 Nov 2000 04:30:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0B8D54446A for ; Wed, 22 Nov 2000 04:29:13 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA23282; Wed, 22 Nov 2000 05:31:09 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 05:26:59 -0500 Message-ID: From: Jonathan Rosenberg To: "'Singh, Manish'" , Jonathan Rosenberg , "'Robin Escolme'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 05:26:58 -0500 > -----Original Message----- > From: Singh, Manish [mailto:manishs@trillium.com] > Sent: Friday, November 03, 2000 1:30 PM > To: 'Jonathan Rosenberg'; Singh, Manish; 'Robin Escolme' > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt > > > Hi : > > Thanks for the response. > > Another concern, section 5 states - > > "Session expiration are mostly of interest to call stateful > proxy servers. However, a stateful proxy server MAY also follow > the rules described here" > > Shouldn't it be mandated by the draft that, if a stateful proxy > (transaction stateful case) server is starting a Session Timer, > it MUST insert a "Record-Route" header in the Invite, prior to > proxying it. No. Its not useful to the proxy to ask for a session timer and then not record-route, but nothing breaks if you don't. I'll mention that its silly not to. > > Since, the procedure is symmetric, i.e. UAS can send a Re-Invite > and become the master, to avoid such proxies being missed out and > later timing out, it MUST be on the path. > > Also, is there any example when a transaction stateful only > proxy would like to start a session timer? Protocol processing has nothing to do with whether you are transaction stateful or call stateful. This fact is hidden from anyone outside of the proxy. Any of the flows, as a result, are the same for both cases. 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 Wed Nov 22 06:30: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 GAA23490 for ; Wed, 22 Nov 2000 06:30:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82F714444C; Wed, 22 Nov 2000 05:30:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from tropiconet.com.br (unknown [200.246.26.146]) by lists.bell-labs.com (Postfix) with ESMTP id 5EDF344343 for ; Wed, 22 Nov 2000 05:29:33 -0500 (EST) Received: from localhost (root@localhost) by tropiconet.com.br (8.9.3 (PHNE_18546)/8.9.3) with SMTP id JAA23408 for sip@lists.bell-labs.com; Wed, 22 Nov 2000 09:29:19 -0200 (VER) From: edson.fassoni@tropiconet.com.br X-OpenMail-Hops: 1 Message-Id: MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="openmail-part-004a762e-00000001" Subject: [SIP] SIP Tutorial Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 09:29:09 -0200 --openmail-part-004a762e-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I=B4m looking for SIP Tutorial Does anyone have a SIP briefly tutorial, or sugestion? Thanks Edson --openmail-part-004a762e-00000001-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 08:20: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 IAA12343 for ; Wed, 22 Nov 2000 08:20:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 618EA44444; Wed, 22 Nov 2000 07:20:09 -0500 (EST) 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 0DC8144388 for ; Wed, 22 Nov 2000 07:19:13 -0500 (EST) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 08:20:57 -0500 Message-ID: From: Alexandre Charest 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] Multi-proxy authentication deadlock Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 08:20:56 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA12343 In (expired) ID draft-sparks-sip-multiproxy-auth-00: "A UAC should be prepared to terminate the deadlock situation caused by a proxy in the chain that expires a challenge after its first successful response." Can somebody give an example of call flow resulting in such a deadlock? I tried many scenarios and I can't figure out what is meant. Thanks. Alexandre Charest Software Designer Mediatrix Telecom Inc. (www.mediatrix.com) tél:(819) 829-8749 #275 fax: (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 Nov 22 08:53: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 IAA19393 for ; Wed, 22 Nov 2000 08:53:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E4074433E; Wed, 22 Nov 2000 07:53:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id C3B8D44339 for ; Wed, 22 Nov 2000 07:52:35 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 22 Nov 2000 13:52:28 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA13785; Wed, 22 Nov 2000 14:51:02 +0100 (BST) Message-ID: <3A1BCF44.7CF69D4A@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: Peter Kjellerstedt Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] More Torture Test Messages Available References: <151F3D2AE9F0D3119E480004ACB8EA3701869309@cluster01.axis.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 13:51:00 +0000 Content-Transfer-Encoding: 7bit Peter Kjellerstedt wrote: > > In test30.txt if the Expires value is in absolute formate, > then a Date header should be supplied too. Otherwise a UA > that has no real-time clock will not be able to tell whether > this is in the future or past. Actually I think the Expires > value should be compared with the Date header if available > since the UA on the other end may have an incorrect notion > of time... But this isn't a MUST so the test message is legal, bear in mind these are torture tests not examples of good practice. > Also, I am still lacking a test for this kind of To/From header: > > To: sip:pkj@axis.com ;tag=123456789@example.com > > and make sure the tag does not end up as a URL parameter... Sorry I forgot to add that one but tests 37 and 38 are pretty similar to this although admittedly they are for a registrar not UAS. 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 Nov 22 09:17:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24726 for ; Wed, 22 Nov 2000 09:17:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0D5B24445E; Wed, 22 Nov 2000 08:17:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 0A83544377 for ; Wed, 22 Nov 2000 08:16:20 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA09588; Wed, 22 Nov 2000 09:15:57 -0500 (EST) Message-ID: <3A1BD51D.B926FE48@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Stuart Wray Cc: Sean Olson , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] URL comparison References: <8025699F.0031C9EA.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 09:15:57 -0500 Content-Transfer-Encoding: 7bit Stuart Wray wrote: > > Henning Schulzrinne wrote: > > > The problem is that with new parameters, older applications won't know > > whether the parameter has a default value and what that might be. > > I don't think this problem has a neat solution. I think what is really > wanted is that URLs which are semantically equivalent should > compare as equal. But if a new parameter changes the semantics > how can older applications ever make the right judgement? > There is a difference between changing the semantics and changing the comparison rules. New parameters can well change the semantics without affecting the To/From call leg comparison which is at issue here. Semantics changes that are mandatory to implement obviously require a Require header. > In this last case do you really mean to ignore the port number if it is not > present in both URLs? I worded my statement carefully to say ;-parameter. The port number does not fall into this category. > > Stuart Wray -- 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 Nov 22 09:21:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25580 for ; Wed, 22 Nov 2000 09:21:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9051F4446F; Wed, 22 Nov 2000 08:21:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6B7054446D for ; Wed, 22 Nov 2000 08:20:31 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA09894; Wed, 22 Nov 2000 09:19:48 -0500 (EST) Message-ID: <3A1BD604.95C670F@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: edson.fassoni@tropiconet.com.br Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Tutorial References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 09:19:48 -0500 Content-Transfer-Encoding: 8bit edson.fassoni@tropiconet.com.br wrote: > > I´m looking for SIP Tutorial > Does anyone have a SIP briefly tutorial, or sugestion? See http://www.cs.columbia.edu/sip for numerous articles and slides. There are also various conferences that offer SIP tutorials. > > Thanks > Edson -- 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 Nov 22 09: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 SMTP id JAA26029 for ; Wed, 22 Nov 2000 09:23:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 50C2A44475; Wed, 22 Nov 2000 08:23:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 4982744474 for ; Wed, 22 Nov 2000 08:22:21 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 22 Nov 2000 14:22:14 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA24002; Wed, 22 Nov 2000 15:20:46 +0100 (BST) Message-ID: <3A1BD63E.713D2344@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: "Fairlie-Cuninghame, Robert" Cc: Sip List Subject: Re: [SIP] More Torture Test Messages Available 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, 22 Nov 2000 14:20:46 +0000 Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > The colon in the user part of Test 36 (the long telephone subscriber) needs > to be quoted. Perhaps you could also put a similar long telephone-subscriber > URL in the Contact - this would test whether the URL was correctly > reproduced if the call is accepted. Actually looking more closely at the URL in the Request URI of test36.txt ... sip:+1-972-555-2222;phone-context=name%40domain;new=user?%22Route:%20X%40Y%3bZ=W%22@gw1.wcom.com;user=phone I think the ':' might be OK as it becomes part of a hname in an escaped header as it follows a '?', i.e. from parsing it into: %22Route:%20X%40Y%3bZ = W%22@gw1.wcom.com;user=phone header = hvalue However this would then mean the following ';' and '=' in the hvalue need to be escaped. Also we would back into the problem of escaped headers not being allowed in Request-URIs. I am a bit uncertain about this now. The spec indicates that they are not allowed (Table 2) and should be removed by a proxy before futher processing (4.3). However there seems to be a feeling that this may not be desirable - should there be a spec change here? 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 Nov 22 09:27:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26883 for ; Wed, 22 Nov 2000 09:27:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F6934447A; Wed, 22 Nov 2000 08:25:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 8B2DF44479 for ; Wed, 22 Nov 2000 08:24:13 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XKW3XF3Y; Wed, 22 Nov 2000 15:21:50 +0100 From: "Hisham Khartabil" 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.50.4133.2400 Subject: [SIP] Via processing rules Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 16:25:21 +0200 Content-Transfer-Encoding: 7bit Hi, section 6.46.3 in rfc2543bis says: Via header fields in responses are processed by a proxy or UAC according to the following rules: 1. The first Via header field should indicate the proxy or client processing this response. If it does not, discard the message. Otherwise, remove this Via field. 2. If there is no second Via header field, this response is destined for this client. Otherwise, use this Via field as the destination, as described in Section 6.46.5. is that implying that a UAC has to forward the request, even if it is an end user? Regards, Hisham Khartabil Hotsip Finland www.hotsip.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 Nov 22 09: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 JAA28195 for ; Wed, 22 Nov 2000 09:33:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B001244481; Wed, 22 Nov 2000 08:33:08 -0500 (EST) 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 6CEC044480 for ; Wed, 22 Nov 2000 08:31:58 -0500 (EST) 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 PAA16044; Wed, 22 Nov 2000 15:30:54 +0100 (MET) Received: by klatt.axis.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Nov 2000 15:29:57 +0100 Message-ID: <151F3D2AE9F0D3119E480004ACB8EA370186930F@cluster01.axis.se> From: Peter Kjellerstedt To: "'Neil Deason'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] More Torture Test Messages Available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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, 22 Nov 2000 15:32:52 +0100 > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: 22 November 2000 14:51 > To: Peter Kjellerstedt > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] More Torture Test Messages Available > > Peter Kjellerstedt wrote: > > > > In test30.txt if the Expires value is in absolute format, > > then a Date header should be supplied too. Otherwise a UA > > that has no real-time clock will not be able to tell whether > > this is in the future or past. Actually I think the Expires > > value should be compared with the Date header if available > > since the UA on the other end may have an incorrect notion > > of time... > > But this isn't a MUST so the test message is legal, bear in > mind these are torture tests not examples of good practice. No it is not a MUST, but you cannot expect me to respond with a 408 if you do not provide me with your time (as I have no RTC...) The description of the test should at least state what will happen for servers without knowledge of time. You could also have another identical test, but with a Date header. And you could actually have a third test with a Date and an Expires header that both are in the past, but where the Expires header is in the future compared to the supplied Date header... > > Also, I am still lacking a test for this kind of To/From header: > > > > To: sip:pkj@axis.com ;tag=123456789@example.com > > > > and make sure the tag does not end up as a URL parameter... > > Sorry I forgot to add that one but tests 37 and 38 are pretty > similar to this although admittedly they are for a registrar > not UAS. True, test 37 tests it. I did not notice it as it was a REGISTER request, and I do not really handle REGISTER requests :) It would probably be a good idea to have an INVITE test for this too. > Cheers, > Neil. //Peter _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 09:36: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 JAA28998 for ; Wed, 22 Nov 2000 09:36:58 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88FD744487; Wed, 22 Nov 2000 08:34:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 5635B44485 for ; Wed, 22 Nov 2000 08:33:55 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 22 Nov 2000 14:33:48 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA28404; Wed, 22 Nov 2000 15:32:22 +0100 (BST) From: "Jo Hornsby" To: "Hisham Khartabil" , Subject: RE: [SIP] Via processing rules Message-ID: <003901c05491$062764d0$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: Wed, 22 Nov 2000 14:32:21 -0000 Content-Transfer-Encoding: 7bit > section 6.46.3 in rfc2543bis says: > > Via header fields in responses are processed by a proxy or UAC > according to the following rules: > 1. The first Via header field should indicate the proxy or client > processing this response. If it does not, discard the message. > Otherwise, remove this Via field. > 2. If there is no second Via header field, this response is destined > for this client. Otherwise, use this Via field as the destination, > as described in Section 6.46.5. > > is that implying that a UAC has to forward the request, even if > it is an end user? (I think you mean response?) I don't see how, unless a UAC received a response that had more than one Via. In such a case, either the UAC wasn't behaving as a UAC (i.e., it was a proxy) when it sent the corresponding request; or something downstream has gone ka ka. - 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 Nov 22 09:42: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 JAA00406 for ; Wed, 22 Nov 2000 09:42:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1CBF34448B; Wed, 22 Nov 2000 08:35:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from felix.intertex.se (unknown [195.22.82.2]) by lists.bell-labs.com (Postfix) with ESMTP id 1924344406 for ; Tue, 21 Nov 2000 18:49:44 -0500 (EST) From: Lars Berggren To: Billy Biggs Cc: "Henning G. Schulzrinne" , Jo Hornsby , Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) In-Reply-To: <20001121112600.A11576@div8.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 01:48:01 +0100 (CET) On Tue, 21 Nov 2000, Billy Biggs wrote: > Henning G. Schulzrinne (hgs@cs.columbia.edu): > > > > So, UA sends a request, it loops back, they end up putting the > > > same tag as the To and as the From... You see the problem? > > > Call-leg endpoint matching is based on: > > > > > > call-id,local-uri,local-tag,remote-uri,remote-tag > > > > > > And you'll end up with the same key for both. The code gets > > > cleaner if you always pick random tags. Unfortunately, > > > call-leg-end matching is very difficult. > > > > I'm not sure I follow this logic. If A calls B and B proxies back to > > A, we get A sending > > > > INVITE B > > From: A > > To: B > > > > The proxy forwards it to A again: > > > > INVITE A > > From: A > > To: B > > > > A can easily tell that it was the origin of the request ("From: A"), > > so I'm not sure how tags get involved here. In this example, the > > request doesn't even have To tags. > > What if A and B are the same URI? How do I tell them apart? The user > answers the call, I send a 200 OK to the INVITE and then ACK it. Now > one of the lines hangs up and I send a BYE: how can I tell which > call-leg end the BYE was meant for when it comes back? Was I even able > to match that ACK properly? Do I have to special-case calls to myself? > That would be really annoying, especially if I'm a gateway. > At a first look I think this is solved by the following phrase in section 6.25 in rfc2543: The "tag" MAY appear in the From field of a request. 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. This seems to imply that the tags should be different to be useful. However, as Billy mentioned, a piece of new text is added which says: A single user agent maintains the same tag at least within the same Call-ID, but it is RECOMMENDED to maintain the same tag across calls and instances of the UA application to allow restarting of a user agent. Since tags primarily are used for differentiating of multiple instances of a SIP address, I think having the same tag across instances of the UA might break the protocol more than it helps. And, why does the UA crash anyway? Well, maybe because identical tags across UAs creates shaky scenarios as the one described earlier in this thread. And if the tags are unique to each UA, the UA may be less likely to have to reboot in the first place. I agree with Billy and would suggest that tags should be unique to each instance of a user agent and maybe even unique to a call. /Lars Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 09:46: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 JAA01390 for ; Wed, 22 Nov 2000 09:46:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C65F344490; Wed, 22 Nov 2000 08:35:23 -0500 (EST) 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 E48C34445D for ; Tue, 21 Nov 2000 22:05:14 -0500 (EST) 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 JAA20480 for ; Wed, 22 Nov 2000 09:41:11 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAAECE; Wed, 22 Nov 2000 09:22:37 +0530 Message-ID: <00d601c05439$bda74920$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Billy Biggs" , =?iso-8859-1?Q?Pascal_Dor=E9?= Cc: "Mo Zonoun" , "SIP List" References: <20001121184306.A12151@div8.net> Subject: Re: [SIP] Changing Codec MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 09:37:33 +0530 Content-Transfer-Encoding: 8bit But if this (re)INVITE fails, shouldn't the original media agreed upon prevail ? That's how I understand (re)INVITES(unlike what you mention about the remote UA tearing down the call). Please clarify. Venkatesh ----- Original Message ----- From: "Billy Biggs" To: "Pascal Doré" Cc: "Mo Zonoun" ; "SIP List" Sent: Wednesday, November 22, 2000 6:13 AM Subject: Re: [SIP] Changing Codec Pascal Doré (pdore@mediatrix.com): > > How do you change codec in a SIP call without disconnecting the > > established call? > > (re)Invite with a new session description Actually, it depends on if you are talking about send codec or receive codec. If you want to change the codec you are sending, then as long as the other end indicated support, you can change any time you like. For example, if I send you SDP that says: m=audio 8552 RTP/AVP 0 1 2 Then you can freely switch between sending audio using codec 0, 1 or 2. If you're feeling cruel, you can use a different codec for every packet. If you want to change which codec you are receiving from the far end, the best you can do is offer a different set of choices using a re-INVITE. So, first maybe you send: m=audio 8552 RTP/AVP 0 1 2 And the far end is sending you codec 1, but you only want to receive codec 0, then you can always re-INVITE with: m=audio 8552 RTP/AVP 0 And force it to use either codec 0 or nothing. Be prepared though that if the remote end can't send codec 0, it might tear down the call (or at best audio won't flow). -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 09: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 JAA02358 for ; Wed, 22 Nov 2000 09:50:44 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C6D4D44495; Wed, 22 Nov 2000 08:35:36 -0500 (EST) 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 3642D44468 for ; Wed, 22 Nov 2000 04:16:04 -0500 (EST) 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 PAA13519 for ; Wed, 22 Nov 2000 15:55:07 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA30FA; Wed, 22 Nov 2000 15:36:34 +0530 Message-ID: <026901c0546d$fbcda260$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: Cc: "Billy Biggs" , =?iso-8859-1?Q?Pascal_Dor=E9?= , "Mo Zonoun" Subject: Re: [SIP] Changing Codec MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 15:51:31 +0530 Content-Transfer-Encoding: 8bit But if this (re)INVITE fails, shouldn't the original media agreed upon prevail ? That's how I understand (re)INVITES(unlike what you mention about the remote UA tearing down the call). Please clarify. Venkatesh > ----- Original Message ----- > From: "Billy Biggs" > To: "Pascal Doré" > Cc: "Mo Zonoun" ; "SIP List" > > Sent: Wednesday, November 22, 2000 6:13 AM > Subject: Re: [SIP] Changing Codec > > > Pascal Doré (pdore@mediatrix.com): > > > > How do you change codec in a SIP call without disconnecting the > > > established call? > > > > (re)Invite with a new session description > > Actually, it depends on if you are talking about send codec or receive > codec. > > If you want to change the codec you are sending, then as long as the > other end indicated support, you can change any time you like. For > example, if I send you SDP that says: > > m=audio 8552 RTP/AVP 0 1 2 > > Then you can freely switch between sending audio using codec 0, 1 or > 2. If you're feeling cruel, you can use a different codec for every > packet. > > > If you want to change which codec you are receiving from the far end, > the best you can do is offer a different set of choices using a > re-INVITE. So, first maybe you send: > > m=audio 8552 RTP/AVP 0 1 2 > > And the far end is sending you codec 1, but you only want to receive > codec 0, then you can always re-INVITE with: > > m=audio 8552 RTP/AVP 0 > > And force it to use either codec 0 or nothing. Be prepared though > that if the remote end can't send codec 0, it might tear down the call > (or at best audio won't flow). > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 10:00:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04545 for ; Wed, 22 Nov 2000 10:00:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58B9444360; Wed, 22 Nov 2000 08:46:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id E53CC444A2 for ; Wed, 22 Nov 2000 08:42:01 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XKW3XFTJ; Wed, 22 Nov 2000 15:39:39 +0100 From: "Hisham Khartabil" To: "Jo Hornsby" , Subject: RE: [SIP] Via processing rules 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: <003901c05491$062764d0$4e34c3c1@ubiquity.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 16:43:10 +0200 Content-Transfer-Encoding: 7bit Sorry, I did mean response. I think the text should explicitly say that in this situation, something downstream has gone ka ka (well, not exactly that:-) ) and how to handle this message. Discard it, perhaps. Regards, Hisham -----Original Message----- From: Jo Hornsby [mailto:jhornsby@ubiquity.net] Sent: Wednesday, 22 November 2000 4:32 PM To: Hisham Khartabil; sip@lists.bell-labs.com Subject: RE: [SIP] Via processing rules > section 6.46.3 in rfc2543bis says: > > Via header fields in responses are processed by a proxy or UAC > according to the following rules: > 1. The first Via header field should indicate the proxy or client > processing this response. If it does not, discard the message. > Otherwise, remove this Via field. > 2. If there is no second Via header field, this response is destined > for this client. Otherwise, use this Via field as the destination, > as described in Section 6.46.5. > > is that implying that a UAC has to forward the request, even if > it is an end user? (I think you mean response?) I don't see how, unless a UAC received a response that had more than one Via. In such a case, either the UAC wasn't behaving as a UAC (i.e., it was a proxy) when it sent the corresponding request; or something downstream has gone ka ka. - 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 Nov 22 10:05: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 KAA05845 for ; Wed, 22 Nov 2000 10:05:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6287C4449A; Wed, 22 Nov 2000 08:35:49 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id CF03D44343 for ; Wed, 22 Nov 2000 05:12:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21198; Wed, 22 Nov 2000 06:12:31 -0500 (EST) Message-Id: <200011221112.GAA21198@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-rosenberg-sip-entfw-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 06:12:31 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Traversal through Residential and Enterprise NATs and Firewalls Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-rosenberg-sip-entfw-00.txt Pages : 15 Date : 21-Nov-00 In this draft, we discuss how SIP can traverse enterprise and residential firewalls and NATs. This environment is challenging because we assume here that the end user has little or no control over the firewall or NAT, and that the firewall or NAT is completely ignorant of SIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sip-entfw-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sip-entfw-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001121111234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-entfw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-entfw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121111234.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 10:11: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 KAA07192 for ; Wed, 22 Nov 2000 10:11:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 985C9444AB; Wed, 22 Nov 2000 08:57:09 -0500 (EST) 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 8DEA8444AA for ; Wed, 22 Nov 2000 08:56:41 -0500 (EST) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 22 Nov 2000 17:54:54 +0200 Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 16:57:46 +0200 Message-ID: From: Itamar Gilad To: "'Jonathan Rosenberg'" , "'David Shrader'" , SIP List Subject: RE: [SIP] Contact: header in re-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: Wed, 22 Nov 2000 16:57:45 +0200 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wed, November 22, 2000 11:40 AM > To: 'David Shrader'; SIP List > Subject: RE: [SIP] Contact: header in re-INVITE > > > Contact should be sent in every INVITE. Due to crash and > restart, what is a > re-INVITE for one user is a new INVITE for another. Shouldn't the INVITE be rejected with a 481 in this case because it arrives with an unknown To tag? Itamar > > If the Contact is different, yes, it should be updated in the > Route set. > This is needed for certain proposed mobility applications, > and I suspect has > some other very useful properties ala third party call control. > > -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: David Shrader [mailto:dshrader@master-consultant.com] > > Sent: Thursday, November 09, 2000 11:17 AM > > To: SIP List > > Subject: [SIP] Contact: header in re-INVITE > > > > > > Table 4 indicates that the Contact: header is mandatory "m" > > in the INVITE > > request. Is this necessary for a re-INVITE message when the > > two endpoints > > have already established communication. > > > > I think this is similar to the Record-Route mechanism in > > which the route is > > recorded once and applies to subsequent requests on the same > > call leg. For > > that matter, if the Contact were to change. Do we change the > > Record-Route/Route as well? > > > > David > > > > ---------------------------- > > David Shrader > > Master Consultant, Inc. > > dshrader@master-consultant.com > > http://www.EyeForTheFuture.com > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 22 10:14: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 KAA07882 for ; Wed, 22 Nov 2000 10:14:36 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1ABF8444A4; Wed, 22 Nov 2000 09:03:09 -0500 (EST) 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 AECEE444A3 for ; Wed, 22 Nov 2000 09:02:50 -0500 (EST) Received: from merlin (user-38lcis8.dialup.mindspring.com [209.86.75.136]) by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id KAA07159; Wed, 22 Nov 2000 10:01:40 -0500 (EST) Reply-To: From: "Gordon Random" To: Cc: Subject: RE: [SIP] SIP Tutorial Message-ID: <001701c05495$42613120$0c01010a@merlin> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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, 22 Nov 2000 10:02:29 -0500 Content-Transfer-Encoding: 8bit Two other good sites for info on SIP. http://www.sipforum.org/ and http://www.sipcenter.com/ Gordon Random Director of Network Services Medetalk, Inc. grandom@medetalk.com -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of edson.fassoni@tropiconet.com.br Sent: Wednesday, November 22, 2000 6:29 AM To: sip@lists.bell-labs.com Subject: [SIP] SIP Tutorial I´m looking for SIP Tutorial Does anyone have a SIP briefly tutorial, or sugestion? Thanks Edson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 10:18: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 KAA08703 for ; Wed, 22 Nov 2000 10:18:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 33C24444B8; Wed, 22 Nov 2000 09:04:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 15B43444B7 for ; Wed, 22 Nov 2000 09:03:15 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA12262; Wed, 22 Nov 2000 10:03:01 -0500 (EST) Message-ID: <3A1BE025.B8C05762@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil Cc: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] Via processing rules 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, 22 Nov 2000 10:03:01 -0500 Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > > Sorry, I did mean response. > > I think the text should explicitly say that in this situation, something > downstream has gone ka ka (well, not exactly that:-) ) and how to handle > this message. Discard it, perhaps. Sorry, but unless we want a 400-page spec, the spec won't be able to spell out every possible error situation that anybody can dream up, particularly since error handling is up to the implementation. Some will be very lenient (or just sloppy), others will be flagging the slightest violation and send along bake-off invitations. -- 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 Nov 22 10:34: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 KAA12319 for ; Wed, 22 Nov 2000 10:34:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5DB4D4434E; Wed, 22 Nov 2000 09:34:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 664EE4433D for ; Wed, 22 Nov 2000 09:33:01 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 22 Nov 2000 09:32:53 -0600 (CST) From: Billy Biggs To: Venkatesh Venkataramanan Cc: sip@lists.bell-labs.com, =?iso-8859-1?Q?Pascal_Dor=E9?= , Mo Zonoun Subject: Re: [SIP] Changing Codec Message-ID: <20001122093253.A13208@div8.net> References: <026901c0546d$fbcda260$0c47a8c0@wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <026901c0546d$fbcda260$0c47a8c0@wipro.com>; from venkatesh.venkataramanan@wipro.com on Wed, Nov 22, 2000 at 03:51:31PM +0530 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 09:32:53 -0600 Venkatesh Venkataramanan (venkatesh.venkataramanan@wipro.com): > > And the far end is sending you codec 1, but you only want to receive > > codec 0, then you can always re-INVITE with: > > > > m=audio 8552 RTP/AVP 0 > > > > And force it to use either codec 0 or nothing. Be prepared though > > that if the remote end can't send codec 0, it might tear down the call > > (or at best audio won't flow). > But if this (re)INVITE fails, shouldn't the original media agreed > upon prevail ? That's how I understand (re)INVITES(unlike what you > mention about the remote UA tearing down the call). Please clarify. I think this was the intention of some folks on this list- that a rejected re-INVITE means the old session stays up. However, I would be more inclined to accept the re-INVITE and shut down the call. The SDP was not malformed, and the remote side has clearly changed its session and is now listening for a different codec. I don't have any implementation experience with multiple codecs though (not with kphone). -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 10:51: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 KAA15361 for ; Wed, 22 Nov 2000 10:51:20 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D51C44469; Wed, 22 Nov 2000 09:51:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 729BD4433D for ; Wed, 22 Nov 2000 09:50:54 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 07:50:45 -0800 Message-ID: From: "Bratakos, Maroula" To: "'Billy Biggs'" , Venkatesh Venkataramanan Cc: sip@lists.bell-labs.com, =?iso-8859-1?Q?Pascal_Dor=E9?= , Mo Zonoun Subject: RE: [SIP] Changing Codec MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 07:50:45 -0800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15361 Actually, I think it is better for the side that issued the re-INVITE to make the decision about whether to return to the original media or tear down the call. If the decision is to return to the original media then no more SIP messages are required since the other side already rejected the new media. If the decision is to terminate the call because the original media can no longer be supported then a BYE can be issued. -Maroula Bratakos -----Original Message----- From: Billy Biggs [mailto:Billy_Biggs@3com.com] Sent: Wednesday, November 22, 2000 7:33 AM To: Venkatesh Venkataramanan Cc: sip@lists.bell-labs.com; Pascal Doré; Mo Zonoun Subject: Re: [SIP] Changing Codec Venkatesh Venkataramanan (venkatesh.venkataramanan@wipro.com): > > And the far end is sending you codec 1, but you only want to receive > > codec 0, then you can always re-INVITE with: > > > > m=audio 8552 RTP/AVP 0 > > > > And force it to use either codec 0 or nothing. Be prepared though > > that if the remote end can't send codec 0, it might tear down the call > > (or at best audio won't flow). > But if this (re)INVITE fails, shouldn't the original media agreed > upon prevail ? That's how I understand (re)INVITES(unlike what you > mention about the remote UA tearing down the call). Please clarify. I think this was the intention of some folks on this list- that a rejected re-INVITE means the old session stays up. However, I would be more inclined to accept the re-INVITE and shut down the call. The SDP was not malformed, and the remote side has clearly changed its session and is now listening for a different codec. I don't have any implementation experience with multiple codecs though (not with kphone). -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 10:56: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 KAA16044 for ; Wed, 22 Nov 2000 10:56:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F15D544473; Wed, 22 Nov 2000 09:53:09 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 97CA24433D for ; Wed, 22 Nov 2000 09:52:09 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Nov 22 10:50:08 EST 2000 Received: by lists.bell-labs.com (Postfix) id 7703544380; Wed, 22 Nov 2000 10:36:59 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 2E82B4437D for ; Wed, 22 Nov 2000 10:36:59 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA21215; Wed, 22 Nov 2000 09:36:56 -0600 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA21212; Wed, 22 Nov 2000 09:36:55 -0600 Message-ID: <3A1BE810.E91D5430@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP LIST Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] INVITE/200 OK/BYE or INVITE/200 OK/ACK/BYE? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 09:36:48 -0600 Content-Transfer-Encoding: 7bit Hi: Assume a UAC sent an INVITE request which reached, through a forking proxy, to 2 UASes. Both of those UASes send a 200 OK upstream. The UAC now gets 2 200 OKs and wants to talk to one and reject the other. Based on some logic, the UAC decides to establish a session with UAS 1, so it sends it a ACK to UAS 1. After sending an ACK to UAS 1, the UAC wants to reject UAS 2. Which is the appropriate message flow: UAC UAS 2 ACK---------> BYE---------> <---------- 200 OK (BYE) OR: UAC UAS 2 BYE---------> <---------- 200 OK (BYE) I believe the first flow is correct (bis, Section 4.2.4, "BYE": "A BYE request from either called or calling party terminates any pending INVITE at a UA, but the INVITE request MUST be completed with a final response and ACK") However, reading some of the postings I get the impression that jives with the second flow. So, which is it? Could the bis draft include something in Section 16.5 "Forking Proxy" call flows; especially where Bell gets two 200 responses from X and Y. The text now says: "He can either send an ACK to both if human intelligence is needed to determine who he wants to talk to or he can automatically reject one of the two calls." It would be good if the text showed how to reject the other call: by sending an ACK immediately followed by a BYE (if first flow is correct), or by sending a BYE (if second flow is correct). Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 11: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 LAA17203 for ; Wed, 22 Nov 2000 11:04:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9043344480; Wed, 22 Nov 2000 10:02:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lists.bell-labs.com (Postfix) with ESMTP id 93B4A44440 for ; Wed, 22 Nov 2000 10:01:22 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eAMG1U619706 for ; Wed, 22 Nov 2000 10:01:40 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 22 Nov 2000 10:01:03 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 22 Nov 2000 10:01:03 -0600 Message-ID: From: Cliff.Harris@nokia.com To: Billy_Biggs@3com.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examp les-00.txt) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 09:52:53 -0600 Why don't you have two fixed and permanent tags: a "from" tag and a "to" tag? Won't that solve the problems with calling yourself? I think you're taking the text in rfc-bis too literally: it is really recommending that the UA be able to recognize its own tags across reboots. Having two tags instead of one doesn't interfere with the intention. > -----Original Message----- > From: EXT Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Tuesday, November 21, 2000 10:40 PM > To: Henning G. Schulzrinne > Cc: Lars Berggren; Jo Hornsby; Alan Johnston; Henry Chen; SIP List > Subject: Re: [SIP] From tags (was: I-D > ACTION:draft-ietf-sip-service-examples-00.txt) > > > Henning G. Schulzrinne (hgs@cs.columbia.edu): > > > I have yet to understand why re-using the same tag across restarts > > hurts anything. After all, you're not worried about > confusing messages > > when a SIP UA is revived. > > > > Maybe we should look at the self-call in a bit more detail > > [...] > > The major problem occurs probably not so much because of > mapping, but > > rather since this is treated as a re-INVITE while the first one is > > still pending. > > Sorry I don't quite understand what you mean. It looks like your > email got a bit truncated. > > To help, I'm going to describe a scenario where a UA calls > itself, and > that UA always uses a local tag (To or From) of 7. Hopefully > this will > help to clarify the problem. > > > I decide to call myself. I create a call-leg struct to > represent it. > Let's call it "Line 1". I send out the initial INVITE: > > [From Line 1] > INVITE sip:me@proxy > Via: SIP/2.0/UDP my.ip > To: > From: ;tag=7 > Call-ID: 5 > > This eventually loops back to me. Now I see coming in: > > INVITE sip:me@proxy > Via: SIP/2.0/UDP some.ip > To: > From: ;tag=7 > Call-ID: 5 > > I check and see there is no To-tag, so this is a new > incoming call. I > create a call struct to represent it, called "Line 2". Line 2 now > begins ringing. I respond with a 180 and the user switches lines and > answers the incoming call: > > [From Line 2] > SIP/2.0 200 OK > Via: SIP/2.0/UDP some.ip > To: ;tag=7 > From: ;tag=7 > Call-ID: 5 > > When I receive this response, I find the related pending > transaction. > Arguably, I could first find which call-leg it is destined to (and > immediately have a problem), but say that I do transaction > mapping first > so we don't break yet. I match the OK and send an ACK: > > [From Line 1] > ACK sip:me@contactaddr > Via: SIP/2.0/UDP my.ip > To: ;tag=7 > From: ;tag=7 > Call-ID: 5 > > At which point the other pending transaction also correctly matches > this ACK to it. > > Now, on Line 2, I decide to hang up. I've had enough of talking to > myself. So, I send a BYE: > > [From Line 2] > BYE sip:me@contact.addr > Via: SIP/2.0/UDP my.ip > To: ;tag=7 > From: ;tag=7 > Call-ID: 5 > > I now see this incoming BYE: > > BYE sip:me@contact.addr > Via: SIP/2.0/UDP some.ip > To: ;tag=7 > From: ;tag=7 > Call-ID: 5 > > Which one of the calls is it for? Is it for the line which > originated > the call, or the line which received the call? > > Using unique tags per call avoids any confusion even in > this case, and > also protects the UA against clients which always use the same tag and > happen to make two calls with the same Call-ID. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 11: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 SMTP id LAA17927 for ; Wed, 22 Nov 2000 11:09:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B2EA4449D; Wed, 22 Nov 2000 10:04:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 2A2994449D for ; Wed, 22 Nov 2000 10:03:33 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 22 Nov 2000 10:03:25 -0600 (CST) From: Billy Biggs To: Vijay Gurbani Cc: SIP LIST Subject: Re: [SIP] INVITE/200 OK/BYE or INVITE/200 OK/ACK/BYE? Message-ID: <20001122100325.A13287@div8.net> References: <3A1BE810.E91D5430@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A1BE810.E91D5430@lucent.com>; from vkg@lucent.com on Wed, Nov 22, 2000 at 09:36:48AM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 10:03:25 -0600 Vijay Gurbani (vkg@lucent.com): > After sending an ACK to UAS 1, the UAC wants to reject UAS 2. Which > is the appropriate message flow: > > UAC UAS 2 > ACK---------> > BYE---------> > <---------- 200 OK (BYE) > > OR: > > UAC UAS 2 > BYE---------> > <---------- 200 OK (BYE) The second flow is incorrect, you must ACK the OK. This is a known area of confusion in the bis draft and it has already been mentioned on this list that it will be clarified. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 11:13: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 LAA18598 for ; Wed, 22 Nov 2000 11:13:57 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1863B44375; Wed, 22 Nov 2000 10:12:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1BD934436D for ; Wed, 22 Nov 2000 10:11:45 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA25991; Wed, 22 Nov 2000 11:13:58 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 11:09:47 -0500 Message-ID: From: Jonathan Rosenberg To: "'Vijay Gurbani'" , SIP LIST Subject: RE: [SIP] INVITE/200 OK/BYE or INVITE/200 OK/ACK/BYE? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 11:09:47 -0500 > -----Original Message----- > From: Vijay Gurbani [mailto:vkg@lucent.com] > Sent: Wednesday, November 22, 2000 10:37 AM > To: SIP LIST > Subject: [SIP] INVITE/200 OK/BYE or INVITE/200 OK/ACK/BYE? > > > Hi: > > Assume a UAC sent an INVITE request which reached, through a > forking proxy, > to 2 UASes. Both of those UASes send a 200 OK upstream. The > UAC now gets 2 > 200 OKs and wants to talk to one and reject the other. > > Based on some logic, the UAC decides to establish a session > with UAS 1, so > it sends it a ACK to UAS 1. > > After sending an ACK to UAS 1, the UAC wants to reject UAS 2. > Which is the > appropriate message flow: > > UAC UAS 2 > ACK---------> > BYE---------> > <---------- 200 OK (BYE) > > OR: > > UAC UAS 2 > BYE---------> > <---------- 200 OK (BYE) > > I believe the first flow is correct (bis, Section 4.2.4, "BYE": > "A BYE request from either called or calling party > terminates any pending > INVITE at a UA, but the INVITE request MUST be completed > with a final > response and ACK") Correct. rfc2543 allowed you to skip the ACK. Bis mandates it. The reason is funamental theorem number 13 of SIP, "all transactions complete independent of any other transactions". This is needed in order to implement a reasonable UA that separates low level transaction processing from higher level call manipulations. Its also needed for sanity in proxies which are transactional. > > However, reading some of the postings I get the impression > that jives with > the second flow. > > So, which is it? > > Could the bis draft include something in Section 16.5 > "Forking Proxy" call > flows; especially where Bell gets two 200 responses from X > and Y. The text > now says: "He can either send an ACK to both if human > intelligence is needed > to determine who he wants to talk to or he can automatically > reject one of > the two calls." > > It would be good if the text showed how to reject the other > call: by sending > an ACK immediately followed by a BYE (if first flow is > correct), or by > sending a BYE (if second flow is correct). Thanks; we'll update. -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 Nov 22 11:35: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 LAA21639 for ; Wed, 22 Nov 2000 11:35:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CEDCB4433D; Wed, 22 Nov 2000 10:35:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 7660B44339 for ; Wed, 22 Nov 2000 10:34:14 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 22 Nov 2000 10:34:07 -0600 (CST) From: Billy Biggs To: Cliff.Harris@nokia.com Cc: SIP List Subject: Crash-Proof UAs (was Re: [SIP] From tags) Message-ID: <20001122103407.A13335@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from Cliff.Harris@nokia.com on Wed, Nov 22, 2000 at 09:52:53AM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 10:34:07 -0600 Cliff.Harris@nokia.com (Cliff.Harris@nokia.com): > Why don't you have two fixed and permanent tags: a "from" tag and a > "to" tag? Won't that solve the problems with calling yourself? > > I think you're taking the text in rfc-bis too literally: it is really > recommending that the UA be able to recognize its own tags across > reboots. Having two tags instead of one doesn't interfere with the > intention. Building a crash-proof UA is not as simple as bis makes it out to be. Rather than putting little hints throughout bis, there should be a separate document describing methods and their problems. My point was that the recommendation will lead to broken behavior. To start this seperate document, here is a list of requirements for Crash-proofness without saving call-state for all active calls: 1. The ability to identify a tag as having originated from the pre-crash UA which this new UA is subsuming. A better idea is to have the tag in two parts, one which is a hash of something unique to the UA, the other something random. These tags MUST be unique to the instance. 2. The ability to choose increasing cseq numbers across reboots and across calls. Just trying to work through what's needed here is very difficult. If you want to keep cseqs monotonotically increasing in each active call, then your cseq must be based on a hash of the call-leg information! Ouch! 3. Some security mechanism such that attacking UAs can't suddenly appear on your phone as if you were already in a call without the phone ringing! 4. Some scheme whereby the remote end knows to send a re-INVITE to kickstart the call. I have doubts about the following scenario: Say that Bob is on the phone to Jill: Bob: "blah blah... Jill? Jill are you there?" Bob suddenly realizes that Jill isn't there! Does Bob: a) Hang up the call and call Jill back or b) Put Jill on hold, and then take Jill off hold, with hopes the phone at the other end has just crashed. I find (b) to be far less likely. Because of the complexity, this should not be discussed in bis. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 11:39:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22167 for ; Wed, 22 Nov 2000 11:39:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE956443A2; Wed, 22 Nov 2000 10:39:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by lists.bell-labs.com (Postfix) with ESMTP id 948F144339 for ; Wed, 22 Nov 2000 10:38:05 -0500 (EST) Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id LAA11549 for ; Wed, 22 Nov 2000 11:36:00 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525699F.005B31A2 ; Wed, 22 Nov 2000 11:36:04 -0500 X-Lotus-FromDomain: TELCORDIA From: "Sanjiv Deshpande" To: sip@lists.bell-labs.com Message-ID: <8525699F.005B30AA.00@notes950.cc.telcordia.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] multiple location Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 11:35:44 -0500 Q: INVITE Sent by UAC got forked and reached two UAS1 and UAS2 , the UAC decided to talk to UAS1. Is it possible that UAS2 (Assuming it is a client also) can make a call to someone else. What I wanted to know is, A user can be contacted at multiple location if one of the location answers a CALL is it possible for somebody else on behalf of that user make CALLS or receive CALLS.... Thanks Sanjiv. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 12:02:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27347 for ; Wed, 22 Nov 2000 12:02:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A29654448E; Wed, 22 Nov 2000 11:02:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6DE0A4448E for ; Wed, 22 Nov 2000 11:01:01 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA26749; Wed, 22 Nov 2000 12:03:19 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 11:59:08 -0500 Message-ID: From: Jonathan Rosenberg To: "'Sanjiv Deshpande'" , sip@lists.bell-labs.com Subject: RE: [SIP] multiple location MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 11:59:06 -0500 SIP is just a protocol. Thats it. Its a tool. If you want device A to call device B, it tells you how to do that. Like all tools, you can use them in many different ways. When you buy a hammer in Home Depot, does it tell you whether to use your left hand or right? How many fingers to grip with it? The size of the nails to use with it? Of course not. However, for some reason that I cannot fathom, many people seem to believe the opposite is true for protocols; that is, protocols need to insist on how syntax and semantics AND how they are applied to solve real world problems. This approach just results in systems that are useful to no one. Would you buy a hammer that said "for nails of length 1 inch only?" I doubt it. So, to be specific, SIP doesn't tell you how to do any of the following: 1. the color of the phones that use SIP 2. the GUI for SIP calls 3. how you build a network of proxy servers 4. whether a phone can make calls while its in a call 5. qualifications for human beings to make use of SIP softphones (i.e., IQ levels, height, or what have you). 6. how many simultaneous calls the device can be in Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Sanjiv Deshpande [mailto:sdeshpan@telcordia.com] > Sent: Wednesday, November 22, 2000 11:36 AM > To: sip@lists.bell-labs.com > Subject: [SIP] multiple location > > > > > > > Q: > INVITE Sent by UAC got forked and reached two UAS1 and UAS2 , > the UAC decided > to talk to UAS1. Is it possible that UAS2 (Assuming it is a > client also) can > make a call to someone else. > > > What I wanted to know is, A user can be contacted at multiple > location if one of > the location answers a CALL is it possible for somebody else > on behalf of that > user make CALLS or receive CALLS.... > > > Thanks > Sanjiv. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 22 12:44: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 MAA05261 for ; Wed, 22 Nov 2000 12:44:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 549DD44468; Wed, 22 Nov 2000 11:44:09 -0500 (EST) 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 7D75E4435A for ; Wed, 22 Nov 2000 11:43:54 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eAMHfm217639; Wed, 22 Nov 2000 18:41:48 +0100 (MET) 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 TAA11132; Wed, 22 Nov 2000 19:41:47 +0200 (EET) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id TAA17485; Wed, 22 Nov 2000 19:41:45 +0200 (EET) Message-ID: <3A1C0541.BD046A3B@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: hgs@cs.columbia.edu, sip@lists.bell-labs.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] draft-rosenberg-sip-app-components-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 19:41:21 +0200 Content-Transfer-Encoding: 7bit Hi, In the draft http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-app-components-00.txt you propose to invoke text to speech services using an INVITE with two "m" sections. One sendonly for the text and the other recvonly for the speech (audio). I see a TSS server as a particular case of a transcoder, that receives media in one format (e.g. GSM) and converts it to another format (e.g. PCM). And I see a transcoder as a particular case of a conference until (MCU). It just takes media from one participant and sends it to the other (adjusting the format). Since conference units are usually INVITEd using one INVITE per conference member, I think transcoder services should be invoked in the same way (with two INVITEs) as it is described in section 3 of: http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt Thus, I would invoke TSS services in the same way. I would send an INVITE with an "m"section consisting of audio and a second INVITE with an "m" section consisting of text. The TSS server would related both INVITEs using the Request-URI (as a conference unit does). I believe this would be a more general way of invoking such a service. Opinions? A minor typo: in section 9 Peter Mataga seems to share Jonathan's email address. Regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 12:48:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07031 for ; Wed, 22 Nov 2000 12:48:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 520EC44489; Wed, 22 Nov 2000 11:48:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 659634446D for ; Wed, 22 Nov 2000 11:47:00 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 22 Nov 2000 17:46:53 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id SAA16739; Wed, 22 Nov 2000 18:45:25 +0100 (BST) From: "Jo Hornsby" To: Cc: , Message-ID: <003f01c054ab$fe070e70$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: <3A1AC25C.DBD7E852@cs.columbia.edu> Subject: [SIP] New Section 6.34 (was: Record-Route consensus) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 17:45:24 -0000 Content-Transfer-Encoding: 7bit Okay, here's a proposal for a new Section 6.34. Hopefully, this is as backwardly-compatible (to 2543) as we could possibly be (that is, it should work with a 2543 proxy, and it even has a good chance of working with a 2543 UA, if it was the one calling). Also, this should solve using Record-Route when a proxy receives a request with a non-SIP Request-URI. The changes are basically now that a proxy is free to put just about any URI into a Record-Route value, as long as it's a UDP SIP URL; and the called UA no-longer does the nasty mangling when copying into the Route. Anyway, without further ado... 6.34 Record-Route 6.34.1 Operation The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. A proxy SHOULD add it to any request for robustness, but a request route, once established, persists until the end of the call leg, regardless of whether the Record-Route header is present in subsequent requests. Some proxies, such as those controlling firewalls or in an automatic call distribution (ACD) system, need to maintain call state and thus need to receive any BYE, re-INVITE and ACK packets for the call. Each Record-Route header field contains a globally reachable SIP URL that identifies a proxy server. Any proxy that wishes to remain in the signalling path of a call leg adds its own SIP URL to the beginning of the list of these fields. This SIP URL MUST represent an address that is reachable via UDP. Requests between both user agents involved in the call leg, in either direction, traverse this route. 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. The UAS copies the Record-Route request header field unchanged into the response. (Record-Route is only relevant for 2xx responses and responses where the server can expect the client to retry for the same Call-ID, as in 401 (Unauthorized) or 484 (Address Incomplete).) *** Should we remove this bit about 401 and 484? It makes things more complicated, and also what if a proxy has collected a load of WWW-Authenticate and Proxy-Authenticate headers into a 401 (Section 12.4 of bis2) -- the Record-Route could be arbitrary. 6.34.2 Construction of Route header If a UAC finds a list of Record-Route header fields in a final response to the initial request in a call leg, it copies this list 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. *** I haven't said initial INVITE here, since wasn't there some talk about abstracting it for, say SUBSCRIBE/NOTIFY purposes? If a UAS finds a list of Record-Route header fields in the initial request in a call leg, it copies this list, maintaining its ordering, into the Route header fields of all subsequent requests within the same call leg. In either case, the UA MUST copy all SIP URLs verbatim. This allows a proxy to add a SIP URL parameter indicating a request's original Request-URI, for instance. If the request/response featured a Contact header field, the UA Contact header value is appended to the list of Route header fields. If this Contact header value is found to have changed in a subsequent request or response, then the new value MUST then be used. Note that the same is not true of changes to list of Record-Route header values. *** If no Contact, should add the From? 6.34.3 Request Destination If a client finds a list of Route header fields in a request, it SHOULD send the request to the first SIP URL in the list. A client MAY forward the request to a designated proxy instead, for example, if it lacks DNS resolution capability. If a client uses the first Route entry to route the request, it removes it. 6.34.4 Syntax The Record-Route header field has the following syntax: Record-Route = "Record-Route" ":" 1#(name-addr *(";" rr-param)) rr-param = generic-param 6.34.5 Example Example for a request where the proxy servers at vanity-domain.com, ieee.org, and sunnydale-high.edu, in that order, insist on being part of subsequent request paths: Record-Route: *** I took the liberty of making the example Record-Route slightly more exotic. &;) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 13:11:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14638 for ; Wed, 22 Nov 2000 13:11:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CFDF8443B0; Wed, 22 Nov 2000 12:11:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 21D49443AB for ; Wed, 22 Nov 2000 12:10:08 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eAMI9fY19399 for ; Wed, 22 Nov 2000 12:09:52 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id MAA11907 for ; Wed, 22 Nov 2000 12:09:40 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA09456 for ; Wed, 22 Nov 2000 12:09:40 -0600 (CST) Received: from ericsson.com (busam52.berkeley.us.am.ericsson.se [138.85.159.202]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA12115 for ; Wed, 22 Nov 2000 12:09:36 -0600 (CST) Message-ID: <3A1C0BD0.7C396E6C@ericsson.com> From: Tony Johansson Organization: Ericsson Inc X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Preview of draft-calhoun-sip-aaa-reqs-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 10:09:20 -0800 Content-Transfer-Encoding: 7bit All, I just wanted to inform you that an updated version of the AAA Requirements for IP Telephony/Multimedia I-D is now available for preview on http://www.diameter.org/draft-ietf-aaa-solutions-01.txt The I-D was submitted to the secretariat, but it will take a few days for it to be available on the archives. Have a great Thanksgiving! /Tony Johansson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 13: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 NAA19561 for ; Wed, 22 Nov 2000 13:25:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1B5744499; Wed, 22 Nov 2000 12:25:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 750AC44498 for ; Wed, 22 Nov 2000 12:24:08 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA27829; Wed, 22 Nov 2000 13:26:25 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 13:22:14 -0500 Message-ID: From: Igor Slepchin To: "'Henning G. Schulzrinne'" Cc: "'Neil Deason'" , Sip List Subject: RE: [SIP] More Torture Test Messages Available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 13:22:05 -0500 > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Test case 41: > > > > I'd argue that this message should be rejected with a 400. > > The version of an HTTP message is indicated by an > HTTP-Version field > in the first line of the message. > > HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT > > Note that the major and minor numbers MUST be treated as separate > integers and that each MAY be incremented higher than a > single digit. Sounds fine except that I don't think this is ever referred to in 2543bis. In fact, the grammar for SIP-Version explicitly disables these tricks: SIP-Version="SIP/2.0" Note that SIP-Version is a literal. I'm not sure what the value of allowing "SIP/02.00" is, but if that's the intention, it should probably be mentioned in the spec. BTW, the change would not be backwards compatible; if it's made, it should probably be mentioned that leading zeros should not be generated. > Wait, if protocol is defined as, say > > protocol-token = "FOO" | "BAR" > > it would be CI. This is consistent with the use in RFC 2616, where all > tokens are defined as CI (such as character-set, content-coding, > transfer-coding, type, subtype, etc. Absolutely. I was just being picky about the grammar of Via headers: it allows protocol name to be something other than SIP, namely, it allows it to be a token. token is case-sensitive, which implies that any protocol name but SIP would be case-sensitive there. Maybe it's easier to just remove token from protocol-name production in Via grammar (after all, what's the meaning of sending a SIP message that is not SIP?) --- 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 Nov 22 14:08: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 OAA00633 for ; Wed, 22 Nov 2000 14:08:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EBD0B4435A; Wed, 22 Nov 2000 13:08:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5A28644339 for ; Wed, 22 Nov 2000 13:07:40 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA28334 for ; Wed, 22 Nov 2000 14:09:48 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 14:05:37 -0500 Message-ID: From: Jonathan Rosenberg To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C054B7.31A8350F" Subject: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 14:05:33 -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_01C054B7.31A8350F Content-Type: text/plain; charset="iso-8859-1" I wanted to draw attention to the following draft which we have submitted. It tackles, and provides what we believe to be at least a workable solution, to the problem of SIP traversal through enterprise firewalls and NATs when there is no ALG at all associated with, or inside of, the firewall. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, November 22, 2000 6:13 AM To: IETF-Announce Cc: sip@lists.bell-labs.com Subject: I-D ACTION:draft-rosenberg-sip-entfw-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Traversal through Residential and Enterprise NATs and Firewalls Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-rosenberg-sip-entfw-00.txt Pages : 15 Date : 21-Nov-00 In this draft, we discuss how SIP can traverse enterprise and residential firewalls and NATs. This environment is challenging because we assume here that the end user has little or no control over the firewall or NAT, and that the firewall or NAT is completely ignorant of SIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sip-entfw-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sip-entfw-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C054B7.31A8350F Content-Type: message/rfc822 To: Subject: Date: Wed, 22 Nov 2000 14:05:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C054B7.31A8350F" ------_=_NextPart_002_01C054B7.31A8350F Content-Type: text/plain ------_=_NextPart_002_01C054B7.31A8350F Content-Type: application/octet-stream; name="ATT04220.txt" Content-Disposition: attachment; filename="ATT04220.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001121111234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-entfw-00.txt ------_=_NextPart_002_01C054B7.31A8350F Content-Type: message/external-body; site="internet-drafts"; dir="draft-rosenberg-sip-entfw-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C054B7.31A8350F-- ------_=_NextPart_000_01C054B7.31A8350F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 14: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 OAA04850 for ; Wed, 22 Nov 2000 14:20:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62206443AB; Wed, 22 Nov 2000 13:20:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C6D8B4439B for ; Wed, 22 Nov 2000 13:19:59 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA28533; Wed, 22 Nov 2000 14:22:16 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 14:18:06 -0500 Message-ID: From: Igor Slepchin To: Igor Slepchin , "'Henning G. Schulzrinne'" Cc: "'Neil Deason'" , Sip List Subject: RE: [SIP] More Torture Test Messages Available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 14:17:57 -0500 > > Wait, if protocol is defined as, say > > > > protocol-token = "FOO" | "BAR" > > > > it would be CI. This is consistent with the use in RFC > 2616, where all > > tokens are defined as CI (such as character-set, content-coding, > > transfer-coding, type, subtype, etc. > > Absolutely. I was just being picky about the grammar of Via > headers: it <...> Arrgh, I guess I missed your point that tokens are CI by default. The reason I missed it is that case-insensitivity of literals is mentioned in Appendix C whereas that of tokens is described in section 6.5. Thank you, 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 Nov 22 16:18: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 QAA11407 for ; Wed, 22 Nov 2000 16:18:26 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34EA144478; Wed, 22 Nov 2000 15:17:23 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mta09.onebox.com (mta09.onebox.com [216.35.104.109]) by lists.bell-labs.com (Postfix) with ESMTP id C786544339 for ; Wed, 22 Nov 2000 14:04:10 -0500 (EST) Received: from onebox.com ([216.33.158.148]) by mta09.onebox.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001122200403.MFUW14355.mta09.onebox.com@onebox.com> for ; Wed, 22 Nov 2000 12:04:03 -0800 Received: from [209.172.143.239] by onebox.com with HTTP; Wed, 22 Nov 2000 12:04:03 -0800 From: "Ramana Bhamidipati" To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1BoxPartBoundary97492344323585974923443" Message-Id: <20001122200403.MFUW14355.mta09.onebox.com@onebox.com> Subject: [SIP] vovida sip-ua Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 14:04:03 -0600 This is a multi-part message in MIME format. --1BoxPartBoundary97492344323585974923443 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit hi recently downloaded the vovida software for sip. Having difficulties in compiling the UA part on solaris 4.2 and above. Has anyone done that? Any info on UA structures/classes hiearchy and complilation will be a added plus! Thanks Ramana ___________________________________________________________________ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com --1BoxPartBoundary97492344323585974923443 Content-type: text/x-vcard; charset=us-ascii Content-Disposition: attachment Content-Description: vCard for Ramana Bhamidipati Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQNCnZlcnNpb246My4wDQpGTjpSYW1hbmEgQmhhbWlkaXBhdGkNCk46Qmhh bWlkaXBhdGk7UmFtYW5hOzs7DQpFTUFJTDtUWVBFPWludGVybmV0OmJoYW1pZGlwYXRpQHpk bmV0b25lYm94LmNvbQ0KVEVMO1RZUEU9dm9pY2UsaG9tZTo4NDctMzM2LTQ3ODcNClRFTDtU WVBFPXZvaWNlLHdvcms6ODQ3LTc4Mi0yNDM0DQplbmQ6dmNhcmQNCg== --1BoxPartBoundary97492344323585974923443-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 16:25:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13029 for ; Wed, 22 Nov 2000 16:25:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71BCF4446E; Wed, 22 Nov 2000 15:25:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.sipcomm.com (mail.sipcomm.com [64.67.24.21]) by lists.bell-labs.com (Postfix) with ESMTP id 027E944353 for ; Wed, 22 Nov 2000 15:24:55 -0500 (EST) Received: from cc444799b [24.180.134.92] by mail.sipcomm.com (SMTPD32-6.00) id AA8D5ED0056; Wed, 22 Nov 2000 16:28:45 -0500 Reply-To: From: "Mohammad Vakil" To: "Ramana Bhamidipati" , Subject: RE: [SIP] vovida sip-ua 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: <20001122200403.MFUW14355.mta09.onebox.com@onebox.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, 22 Nov 2000 16:24:55 -0500 Content-Transfer-Encoding: 7bit You can sign up for email list at vovida. All these kinds of problems specific to Vovida's stack are discussed there. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Ramana Bhamidipati Sent: Wednesday, November 22, 2000 3:04 PM To: sip@lists.bell-labs.com Subject: [SIP] vovida sip-ua hi recently downloaded the vovida software for sip. Having difficulties in compiling the UA part on solaris 4.2 and above. Has anyone done that? Any info on UA structures/classes hiearchy and complilation will be a added plus! Thanks Ramana ___________________________________________________________________ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.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 Nov 22 16: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 QAA20222 for ; Wed, 22 Nov 2000 16:54:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9398544484; Wed, 22 Nov 2000 15:54:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id A3CB344339 for ; Wed, 22 Nov 2000 15:53:54 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eAMLrkY29411; Wed, 22 Nov 2000 15:53:46 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eAMLpNT10366; Wed, 22 Nov 2000 15:51:23 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA18710; Wed, 22 Nov 2000 15:53:46 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id PAA14268; Wed, 22 Nov 2000 15:54:02 -0600 (CST) Message-Id: <200011222154.PAA14268@b04a24.exu.ericsson.se> To: sip-t@egroups.com Reply-To: sip-t@egroups.com From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] New ISUP mapping draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 15:54:02 -0600 (CST) Content-Transfer-Encoding: 7bit A new ISUP to SIP mapping draft had been completed. Due to the overwhelming number of contributions pouring in prior to the November 24th deadline, the I-D editor is currently running somewhat slower than usual. Until it becomes available from the IETF website, you may retrieve a copy from: http://ia.yimg.com/a/5e379c0a/h/48c55585/draft-ietf-sip-isup-00.txt Please post all comments and replies to the sip-t@egroups.com mailing list. Thanks. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 17:03: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 RAA22420 for ; Wed, 22 Nov 2000 17:03:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94AB64448D; Wed, 22 Nov 2000 16:03:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E410444377 for ; Wed, 22 Nov 2000 16:02:53 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA00479; Wed, 22 Nov 2000 17:04:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 17:00:41 -0500 Message-ID: From: Jonathan Rosenberg To: "'Bratakos, Maroula'" , "'Billy Biggs'" , Venkatesh Venkataramanan Cc: sip@lists.bell-labs.com, =?iso-8859-1?Q?Pascal_Dor=E9?= , Mo Zonoun Subject: RE: [SIP] Changing Codec MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 17:00:30 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA22420 Either way is fine. Its a matter of local choice. I don't think the spec needs to say anything except that a rejection of a reinvite returns to the previous session state. -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: Bratakos, Maroula [mailto:mbratakos@nuera.com] > Sent: Wednesday, November 22, 2000 10:51 AM > To: 'Billy Biggs'; Venkatesh Venkataramanan > Cc: sip@lists.bell-labs.com; Pascal Doré; Mo Zonoun > Subject: RE: [SIP] Changing Codec > > > Actually, I think it is better for the side that issued the > re-INVITE to > make the decision about whether to return to the original > media or tear down > the call. If the decision is to return to the original media > then no more > SIP messages are required since the other side already > rejected the new > media. If the decision is to terminate the call because the > original media > can no longer be supported then a BYE can be issued. > > -Maroula Bratakos > > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Wednesday, November 22, 2000 7:33 AM > To: Venkatesh Venkataramanan > Cc: sip@lists.bell-labs.com; Pascal Doré; Mo Zonoun > Subject: Re: [SIP] Changing Codec > > > Venkatesh Venkataramanan (venkatesh.venkataramanan@wipro.com): > > > > > And the far end is sending you codec 1, but you only > want to receive > > > codec 0, then you can always re-INVITE with: > > > > > > m=audio 8552 RTP/AVP 0 > > > > > > And force it to use either codec 0 or nothing. Be > prepared though > > > that if the remote end can't send codec 0, it might tear > down the call > > > (or at best audio won't flow). > > > But if this (re)INVITE fails, shouldn't the original media agreed > > upon prevail ? That's how I understand (re)INVITES(unlike what you > > mention about the remote UA tearing down the call). Please clarify. > > I think this was the intention of some folks on this list- that a > rejected re-INVITE means the old session stays up. > > However, I would be more inclined to accept the re-INVITE and shut > down the call. The SDP was not malformed, and the remote side has > clearly changed its session and is now listening for a > different codec. > > I don't have any implementation experience with multiple codecs > though (not with kphone). > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 22 17:06: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 RAA23294 for ; Wed, 22 Nov 2000 17:06:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F12C444A1; Wed, 22 Nov 2000 16:04:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B1BE3444A1 for ; Wed, 22 Nov 2000 16:03:22 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA00496; Wed, 22 Nov 2000 17:05:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 17:01:20 -0500 Message-ID: From: Jonathan Rosenberg To: "'Itamar Gilad'" , Jonathan Rosenberg , "'David Shrader'" , SIP List Subject: RE: [SIP] Contact: header in re-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: Wed, 22 Nov 2000 17:01:13 -0500 That depends on whether the UAS is using To tags that are persistent across reboots. There is a separate thread running now on this subject. -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: Itamar Gilad [mailto:ItamarG@tlv.radvision.com] > Sent: Wednesday, November 22, 2000 9:58 AM > To: 'Jonathan Rosenberg'; 'David Shrader'; SIP List > Subject: RE: [SIP] Contact: header in re-INVITE > > > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Wed, November 22, 2000 11:40 AM > > To: 'David Shrader'; SIP List > > Subject: RE: [SIP] Contact: header in re-INVITE > > > > > > Contact should be sent in every INVITE. Due to crash and > > restart, what is a > > re-INVITE for one user is a new INVITE for another. > > Shouldn't the INVITE be rejected with a 481 in this case > because it arrives > with an unknown To tag? > > Itamar > > > > If the Contact is different, yes, it should be updated in the > > Route set. > > This is needed for certain proposed mobility applications, > > and I suspect has > > some other very useful properties ala third party call control. > > > > -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: David Shrader [mailto:dshrader@master-consultant.com] > > > Sent: Thursday, November 09, 2000 11:17 AM > > > To: SIP List > > > Subject: [SIP] Contact: header in re-INVITE > > > > > > > > > Table 4 indicates that the Contact: header is mandatory "m" > > > in the INVITE > > > request. Is this necessary for a re-INVITE message when the > > > two endpoints > > > have already established communication. > > > > > > I think this is similar to the Record-Route mechanism in > > > which the route is > > > recorded once and applies to subsequent requests on the same > > > call leg. For > > > that matter, if the Contact were to change. Do we change the > > > Record-Route/Route as well? > > > > > > David > > > > > > ---------------------------- > > > David Shrader > > > Master Consultant, Inc. > > > dshrader@master-consultant.com > > > http://www.EyeForTheFuture.com > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > 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 Nov 22 17:08: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 RAA23721 for ; Wed, 22 Nov 2000 17:08:50 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CC89B444A8; Wed, 22 Nov 2000 16:07:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 3FA63444A8 for ; Wed, 22 Nov 2000 16:06:14 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eAMM63Y05206; Wed, 22 Nov 2000 16:06:06 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id QAA04206; Wed, 22 Nov 2000 16:06:03 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA19372; Wed, 22 Nov 2000 16:06:02 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id QAA14339; Wed, 22 Nov 2000 16:06:18 -0600 (CST) Message-Id: <200011222206.QAA14339@b04a24.exu.ericsson.se> To: sip-events@egroups.com Reply-To: sip-events@egroups.com From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] New SUBSCRIBE/NOTIFY draft available Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 16:06:18 -0600 (CST) Content-Transfer-Encoding: 7bit A new SUBSCRIBE/NOTIFY draft (-02) has been submitted. Until it appears on the IETF website, you may retreive a copy from: http://ia.yimg.com/a/5e379c0a/h/57a388ad/draft-roach-sip-subscribe-notify-02.txt Please send comments and replies to the sip-events@egroups.com mailing list. I believe that this draft incorporates all of the concerns which have been raised with the -01 draft; please inform me if I've overlooked anything. Changes include: - Multiple contacts per SUBSCRIBE message disallowed. - Contact header now required in NOTIFY messages. - Distinction between third party/call member events removed. - Distinction between call-related/resource-related events removed. - Clarified that subscribers must expect NOTIFY messages before the SUBSCRIBE transaction completes - Added immediate NOTIFY message after successful SUBSCRIBE; this solves a myriad of issues, most having to do with forking. - Added discussion of "undefined state" (before a NOTIFY arrives). - Added mechanism for notifiers to shorten/cancel outstanding subscriptions. - Removed open issue about appropriateness of new "489" response. - Removed all discussion of out-of-band subscriptions. - Added brief discussion of event state polling. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 17: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 SMTP id RAA24523 for ; Wed, 22 Nov 2000 17:12:20 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ECC6B444B4; Wed, 22 Nov 2000 16:12:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id AA311444B3 for ; Wed, 22 Nov 2000 16:11:29 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eAMMBJY07411; Wed, 22 Nov 2000 16:11:22 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id QAA05619; Wed, 22 Nov 2000 16:11:19 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA19653; Wed, 22 Nov 2000 16:11:19 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id QAA14376; Wed, 22 Nov 2000 16:11:35 -0600 (CST) Message-Id: <200011222211.QAA14376@b04a24.exu.ericsson.se> To: sip-events@egroups.com In-Reply-To: <200011222206.QAA14339@b04a24.exu.ericsson.se> from "Adam B. Roach" at Nov 22, 2000 04:06:18 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: [sip-events] New SUBSCRIBE/NOTIFY draft available Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 16:11:35 -0600 (CST) Content-Transfer-Encoding: 7bit >http://ia.yimg.com/a/5e379c0a/h/57a388ad/draft-roach-sip-subscribe-notify-02.txt It has been brought to my attention that this link doesn't always work; you may instead need to select the draft from this page: http://briefcase.yahoo.com/bc/adamr?c&.flabel=fld6&.src=bc -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 17:17:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25589 for ; Wed, 22 Nov 2000 17:17:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F131444BB; Wed, 22 Nov 2000 16:12:26 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5E1B5444B3 for ; Wed, 22 Nov 2000 16:11:33 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA00570; Wed, 22 Nov 2000 17:13:51 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 17:09:40 -0500 Message-ID: From: Jonathan Rosenberg To: "'Alexandre Charest'" , sip@lists.bell-labs.com Subject: RE: [SIP] Multi-proxy authentication deadlock MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 17:09:33 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA25589 Hmm; I could not create the case either. The case that I thought would cause a deadlock does not, in fact. Robert? -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: Alexandre Charest [mailto:acharest@mediatrix.com] > Sent: Wednesday, November 22, 2000 8:21 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Multi-proxy authentication deadlock > > > In (expired) ID draft-sparks-sip-multiproxy-auth-00: > > "A UAC should be prepared to terminate the deadlock situation > caused by a > proxy in the chain that expires a challenge after its first successful > response." > Can somebody give an example of call flow resulting in such a > deadlock? I > tried many scenarios and I can't figure out what is meant. > Thanks. > > Alexandre Charest > Software Designer > Mediatrix Telecom Inc. (www.mediatrix.com) > tél:(819) 829-8749 #275 > fax: (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 Wed Nov 22 17:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05021 for ; Wed, 22 Nov 2000 17:55:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4DD8644353; Wed, 22 Nov 2000 16:55:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C2A0B44339 for ; Wed, 22 Nov 2000 16:54:36 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA00939; Wed, 22 Nov 2000 17:56:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 17:52:42 -0500 Message-ID: From: Jonathan Rosenberg To: "'Jo Hornsby'" , hgs@cs.columbia.edu Cc: sip@lists.bell-labs.com, Billy_Biggs@3com.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 17:52:34 -0500 Before we begin writing new text, lets look at the sub-problems and build up a solution. I have another possibility that may be the best of all worlds. I'll start with Roberts list: 1. non SIP URLs in request URI We can either define record-route parameters, or else make sure that the URL put into the record route is a sip url. I originally propose RR parameters, but I think insisting on a SIP URL is backwards compatible and more reasonable. That seems to be consensus. 2. transaction ID in the reverse direction This was the problem that if there was a spiral in the forward direction, and the current bis approach was used by the UAS to construct the Route header, a request would arrive twice at the spiraled-at proxy. These could be identified as separate transactions (as a result of Via header differences), but there is no way to determine which of the two iterations through it is. The solution is that the request URI need some info that the proxy created and is returned to it. There seems to be little disagreement on that. 3. Proxy doesn't see URI parameters it inserted in RR, returned to it in request URI This is a consequence of the current bis text for building the route. Proposed solution for this component is that the construction process at the UAS has to copy the URI parameters from the RR rather than the Contact/From. 4. detecting new behavior I don't think this is an issue, since we need a solution thats backwards compatible. 5. (this one is my own) The request URI should refer to the resource for whom the message is destined The solutions proposed are either to have the UAS and UAC construct the Route differently (as is done in the current bis), else Jo's text here where this information is carried somehow as parameters. I think this is a big hack, and quite a pain. When a proxy receives a re-INVITE, it will have a hard time knowing which direction the re-INVITE is going, and consequently, which of the pieces of info to extract for processing purposes. Putting it all together, its clear from (1) that the record routes must always be SIP URLs. From 2 and 3, at least the parameters placed into the RR should be copied into the Route by both sides, and from 5, the URI should contain information that identifies the recipient of the message, different in both directions. My new proposal does all of the above, and requires no mangling of RR in the UA. Here's how it goes. When a request arrives, and a proxy record-routes, it places a URI into the RR which identifies the *calling UA* as a resource on this proxy. This URI can be derived from the Contact/From, but should not be exactly equal to it. This must be a SIP URL. THe UAS copies the RR set into the response. It also constructs a Route header by taking the RR's in order, and adding the Contact from the INVITE at the end. Now, here's the trick. As the response traverses the proxies, any proxy that record-routed, finds its RR entry, and *replaces it* with a new URI; this URI identifies the called party at this server. Probably this is the request URI that was originally received in the INVITE. The UAC then constructs the Route as defined in rfc2543. Now, the result of this is that the URIs in the two Route sets are different; they identify the actual recipient of the message, and they are inserted by the proxy and can thus be set by the proxy. Seems to have everything we want. Here's an example. A calls B, through a record-routing Proxy P1. Here are message snipits: A->P1 INVITE sip:B@example.com Contact: sip:A@host.example.com P1->B INVITE sip:B@host.example.com Contact: sip:A@host.example.com Record-Route: B->P1 200 OK Contact: sip:B@host.example.com Record-Route P1->B 200 OK Contact: sip:B@host.example.com Record-Route The Route constructed by A is: sip:B@proxy.example.com sip:B@host.example.com and by B: sip:A@proxy.example.com sip:A@host.example.com This is similar to Jo's proposal but maintains the property that a request from A to B has a URI that always points to a resource that gets routed to B, and vice a versa (in Jo's case, the URI is the same in both directions). Thus, I think it satisfies everyone. Note that maddr is no longer needed so long as the host port gets routed back to the same server; of course it can put maddr if it likes. The drawback is that the proxy needs to do a bit more work. Not a lot, though. Comments? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Wednesday, November 22, 2000 12:45 PM > To: hgs@cs.columbia.edu > Cc: sip@lists.bell-labs.com; Billy_Biggs@3com.com > Subject: [SIP] New Section 6.34 (was: Record-Route consensus) > > > Okay, here's a proposal for a new Section 6.34. Hopefully, this > is as backwardly-compatible (to 2543) as we could possibly be > (that is, it should work with a 2543 proxy, and it even has a > good chance of working with a 2543 UA, if it was the one calling). > > Also, this should solve using Record-Route when a proxy receives > a request with a non-SIP Request-URI. The changes are basically > now that a proxy is free to put just about any URI into a > Record-Route value, as long as it's a UDP SIP URL; and the called > UA no-longer does the nasty mangling when copying into the Route. > > Anyway, without further ado... > > > > 6.34 Record-Route > > > 6.34.1 Operation > > The Record-Route request and response header field is added to a > request by any proxy that insists on being in the path of subsequent > requests for the same call leg. A proxy SHOULD add it to any request > for robustness, but a request route, once established, persists until > the end of the call leg, regardless of whether the Record-Route header > is present in subsequent requests. > > Some proxies, such as those controlling firewalls or in an > automatic call distribution (ACD) system, need to maintain call > state and thus need to receive any BYE, re-INVITE and ACK packets > for the call. > > Each Record-Route header field contains a globally reachable SIP URL > that identifies a proxy server. Any proxy that wishes to remain in > the signalling path of a call leg adds its own SIP URL to the > beginning of the list of these fields. This SIP URL MUST represent an > address that is reachable via UDP. Requests between both user agents > involved in the call leg, in either direction, traverse this route. > > 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. > > The UAS copies the Record-Route request header field unchanged into > the response. (Record-Route is only relevant for 2xx responses and > responses where the server can expect the client to retry for the same > Call-ID, as in 401 (Unauthorized) or 484 (Address Incomplete).) > > *** Should we remove this bit about 401 and 484? It makes things > more complicated, and also what if a proxy has collected a load > of WWW-Authenticate and Proxy-Authenticate headers into a > 401 (Section 12.4 of bis2) -- the Record-Route could be > arbitrary. > > > 6.34.2 Construction of Route header > > If a UAC finds a list of Record-Route header fields in a final > response to the initial request in a call leg, it copies this list > 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. > > *** I haven't said initial INVITE here, since wasn't there > some talk about > abstracting it for, say SUBSCRIBE/NOTIFY purposes? > > If a UAS finds a list of Record-Route header fields in the initial > request in a call leg, it copies this list, maintaining its ordering, > into the Route header fields of all subsequent requests within the > same call leg. > > In either case, the UA MUST copy all SIP URLs verbatim. > > This allows a proxy to add a SIP URL parameter indicating a > request's original Request-URI, for instance. > > If the request/response featured a Contact header field, the > UA Contact > header value is appended to the list of Route header fields. If this > Contact header value is found to have changed in a subsequent request > or response, then the new value MUST then be used. Note that the same > is not true of changes to list of Record-Route header values. > > *** If no Contact, should add the From? > > > 6.34.3 Request Destination > > If a client finds a list of Route header fields in a request, it > SHOULD send the request to the first SIP URL in the list. A client > MAY forward the request to a designated proxy instead, for example, if > it lacks DNS resolution capability. If a client uses the first Route > entry to route the request, it removes it. > > > 6.34.4 Syntax > > The Record-Route header field has the following syntax: > > Record-Route = "Record-Route" ":" 1#(name-addr *(";" rr-param)) > rr-param = generic-param > > > 6.34.5 Example > > Example for a request where the proxy servers at vanity-domain.com, > ieee.org, and sunnydale-high.edu, in that order, insist on being part > of subsequent request paths: > > Record-Route: > > > > *** I took the liberty of making the example Record-Route slightly > more exotic. &;) > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 22 18:11: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 SAA08634 for ; Wed, 22 Nov 2000 18:11:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4B198443DF; Wed, 22 Nov 2000 17:11:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 76FF34433F for ; Wed, 22 Nov 2000 17:10:02 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 22 Nov 2000 17:09:47 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Jo Hornsby , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <20001122170947.A13989@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Wed, Nov 22, 2000 at 05:52:34PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 17:09:47 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > 5. (this one is my own) The request URI should refer to the resource > for whom the message is destined > > The solutions proposed are either to have the UAS and UAC construct > the Route differently (as is done in the current bis), else Jo's text > here where this information is carried somehow as parameters. I think > this is a big hack, and quite a pain. When a proxy receives a > re-INVITE, it will have a hard time knowing which direction the > re-INVITE is going, and consequently, which of the pieces of info to > extract for processing purposes. The proxy should look at the To and the From to tell direction, instead of doing this ugly hack! [1] The only note then is that if a UA calls itself through a Record-Route'ing outbound proxy, then the tags it inserts had better be different. [I think you've heard that argument before!] Still, bis shouldn't talk about any of this. Keep the spec really simple, and let proxies which need to keep state figure out how to record-route to their advantage. Jo's text is pretty much on the mark. [1] Or, it can always just look at which address is at the end of the Route... Regardless, your suggestion is an ugly hack. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 18:15: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 SAA09556 for ; Wed, 22 Nov 2000 18:15:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9C3244488; Wed, 22 Nov 2000 17:15:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9F0A04447E for ; Wed, 22 Nov 2000 17:14:26 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01076; Wed, 22 Nov 2000 18:16:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 18:12:31 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , Jonathan Rosenberg Cc: Jo Hornsby , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 18:12:25 -0500 > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Wednesday, November 22, 2000 6:10 PM > To: Jonathan Rosenberg > Cc: Jo Hornsby; hgs@cs.columbia.edu; sip@lists.bell-labs.com > Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) > > > Jonathan Rosenberg (jdrosen@dynamicsoft.com): > > > 5. (this one is my own) The request URI should refer to the resource > > for whom the message is destined > > > > The solutions proposed are either to have the UAS and UAC construct > > the Route differently (as is done in the current bis), else > Jo's text > > here where this information is carried somehow as > parameters. I think > > this is a big hack, and quite a pain. When a proxy receives a > > re-INVITE, it will have a hard time knowing which direction the > > re-INVITE is going, and consequently, which of the pieces of info to > > extract for processing purposes. > > > The proxy should look at the To and the From to tell direction, > instead of doing this ugly hack! [1] > > The only note then is that if a UA calls itself through a > Record-Route'ing outbound proxy, then the tags it inserts had > better be > different. [I think you've heard that argument before!] > > > Still, bis shouldn't talk about any of this. Keep the spec really > simple, and let proxies which need to keep state figure out how to > record-route to their advantage. Jo's text is pretty much on > the mark. > > > [1] Or, it can always just look at which address is at the > end of the > Route... Regardless, your suggestion is an ugly hack. Billy, I prefer to hold list discussions based on technical issues rather than name calling. Proxies route based on request URIs. I'll say it again. Proxies route based on request URIs. As such, it is really important that the request URI, without needing to examine the To/From, by itself, indicate the resource to whom the request is targeted. -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 Nov 22 18:17:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10072 for ; Wed, 22 Nov 2000 18:17:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC12F444A0; Wed, 22 Nov 2000 17:17:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 8227B4449C for ; Wed, 22 Nov 2000 17:16:29 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 22 Nov 2000 17:16:20 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Jo Hornsby , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <20001122171620.A14017@div8.net> References: <20001122170947.A13989@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20001122170947.A13989@div8.net>; from Billy_Biggs@3com.com on Wed, Nov 22, 2000 at 05:09:47PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 17:16:20 -0600 Billy Biggs (Billy_Biggs@3com.com): > The proxy should look at the To and the From to tell direction, > instead of doing this ugly hack! [1] To clarify myself, I refer to Jonathan's hack of having the proxy mangle the Record-Route in the response which comes back. I should have quoted his message better. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 18: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 SAA11863 for ; Wed, 22 Nov 2000 18:25:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78D74443BB; Wed, 22 Nov 2000 17:25:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id BB9E844339 for ; Wed, 22 Nov 2000 17:24:21 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 22 Nov 2000 17:24:10 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Jo Hornsby , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <20001122172410.A14046@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Wed, Nov 22, 2000 at 06:12:25PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 17:24:10 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > Billy, I prefer to hold list discussions based on technical issues > rather than name calling. I apologize. I was very, very unnecessarily harsh. > Proxies route based on request URIs. I'll say it again. Proxies route > based on request URIs. As such, it is really important that the > request URI, without needing to examine the To/From, by itself, > indicate the resource to whom the request is targeted. Say my proxy inserts as a record route: When a re-INVITE comes in, is it really addressed to Billy_Biggs@3com.com? No. The request is actually addressed to some state value for the active call inside the 3com.com proxy. To me, it would be much better for the proxy to use: Which correctly identifies this state key. It's not like the proxy needs to look up and see how to route the message to Billy_Biggs@3com.com. This routing is handled by the Route. No? -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 20:08: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 UAA11487 for ; Wed, 22 Nov 2000 20:08:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A9C54433F; Wed, 22 Nov 2000 19:08:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 533B544339 for ; Wed, 22 Nov 2000 19:07:25 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA29970; Wed, 22 Nov 2000 20:07:13 -0500 (EST) Message-ID: <3A1C6DC1.E2F86A1A@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: "'Neil Deason'" , Sip List Subject: Re: [SIP] More Torture Test Messages Available 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, 22 Nov 2000 20:07:13 -0500 Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > > Sounds fine except that I don't think this is ever referred to in 2543bis. > In fact, the grammar for SIP-Version explicitly disables these tricks: > > SIP-Version="SIP/2.0" > > Note that SIP-Version is a literal. I'm not sure what the value of allowing > "SIP/02.00" is, but if that's the intention, it should probably be mentioned > in the spec. BTW, the change would not be backwards compatible; if it's > made, it should probably be mentioned that leading zeros should not be > generated. I agree that adding leading zeros gains nothing. Given the low likelihood of version changes, it doesn't seem worth treating it as anything other than a string. For consistency, I will add the CI description: The string is case-insensitive, but implementations {\MUST} use upper-case. \motivation{Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference.} -- 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 Nov 22 21:28: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 VAA27095 for ; Wed, 22 Nov 2000 21:28:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB54544377; Wed, 22 Nov 2000 20:28:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.langoo.com (mail.langoo.com [216.10.100.121]) by lists.bell-labs.com (Postfix) with ESMTP id 65F8644339 for ; Wed, 22 Nov 2000 20:27:07 -0500 (EST) Received: from AspEmail [10.32.12.197] by mail.langoo.com (SMTPD32-6.05) id A06615F2002E; Wed, 22 Nov 2000 18:26:46 -0800 From: "kajun Robert" To: sip@lists.bell-labs.com MIME-Version: 1.0 Message-Id: <200011221826254.SM00159@AspEmail> Subject: [SIP] the parser Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 22 Nov 2000 18:26:48 -0800 hi, I don't know what the parser should do and it seems that the parser has muddled me. Can you help me? I think it should check the message byte-by-byte to ensure that every character has fallen into a specific field, such as unreserved filed, DIGIT filed etc. Also the parser can find the syntax error besides the characters falling into some fields. For example, the parser should find the errors such as "%4q", 101.3332.3.5 (the Ipv4address) and so on in the Request-URL, although the characters are allowed to appear in the message. Is that true? Also I am not sure the @ character can be escaped. If it can be escaped, the parser would not have mechanism to distinguish the one that the Spec requests with the one that the user's own escaped character? Thanks. Robert Kajun ________________________________________________________________________ Get Your Free International E-mail from Langoo.com at http://www.langoo.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 Nov 22 23:01: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 XAA13729 for ; Wed, 22 Nov 2000 23:01:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 59B8644426; Wed, 22 Nov 2000 22:01:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sargasso.cse.msu.edu (sargasso.cse.msu.edu [35.9.20.10]) by lists.bell-labs.com (Postfix) with ESMTP id 2125544339 for ; Wed, 22 Nov 2000 22:00:11 -0500 (EST) Received: from ft1.cse.msu.edu (ft1.cse.msu.edu [35.9.24.111]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with ESMTP id XAA26703 for ; Wed, 22 Nov 2000 23:00:03 -0500 (EST) From: Arun Kumar Chippada To: sip@lists.bell-labs.com In-Reply-To: <200011221826254.SM00159@AspEmail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Help with sip Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 23:00:03 -0500 (EST) Dear All, We want to know whether it is possible to run a SIP Proxy Server and a SIP User Agent on the same machine. Has anyone ever tried to do this? Arun. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 23:02: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 XAA13922 for ; Wed, 22 Nov 2000 23:02:58 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56269444A7; Wed, 22 Nov 2000 22:02:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id A9F764449C for ; Wed, 22 Nov 2000 22:01:47 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 20:01:44 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'Billy Biggs'" Cc: Jo Hornsby , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 20:01:42 -0800 Hi Jonathan, That is a very interesting suggestion. I like the motivation to have the Route's different in each direction. You said that in one direction the Route was Route: A@proxy.blah.com and in the other direction Route: B@proxy.blah.com Only the proxy understands the significance of A and B so is there any point in proscribing that it must be of the above form, for instance, can you see any disadvantages of: Route: proxy.blah.com;rstate=A and Route: proxy.blah.com;rstate=B If the answer is that you would like the base URL to be different for robustness, ok that's fine. In that case A and B could just as easily be a unique token, eg "1" & "2" or literally the characters "A" and "B" (regardless of the request URI). Should we just leave it up to the proxy ? Does the user part need to be present at all? Additionally, if the proxy is keeping full call state, eg based on unique Call-Id. Is it REQUIRED to mess with the Record-Route in the response. Otherwise, adding a simple Record-Route: proxy.blah.com would be sufficient. [If the request spirals it will need to add something different the second time but it still doesn't need to be different in each direction.] What I am getting at is are you trying to make this a requirement for the sake of protocol "invariant-ness" or merely as a helpful recommendation for proxies not wanting to keep full state. ie, SHOULD or MUST Regardless of the above handling by the proxies, it seems that we have reached a consensus that the UAS should no longer mangle the reverse Route which I think is an important point. I believe it will be a lot easier to change how proxies handle the Record-Route processing than the behaviour of the UA's already out there - so the sooner the UA behaviour is settled the better. It also makes the UA behaviour a lot simpler - which is always a good thing. Agreed? Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, November 23, 2000 7:12 AM > To: 'Billy Biggs'; Jonathan Rosenberg > Cc: Jo Hornsby; hgs@cs.columbia.edu; sip@lists.bell-labs.com > Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) > > > > > > > > -----Original Message----- > > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > > Sent: Wednesday, November 22, 2000 6:10 PM > > To: Jonathan Rosenberg > > Cc: Jo Hornsby; hgs@cs.columbia.edu; sip@lists.bell-labs.com > > Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) > > > > > > Jonathan Rosenberg (jdrosen@dynamicsoft.com): > > > > > 5. (this one is my own) The request URI should refer to > the resource > > > for whom the message is destined > > > > > > The solutions proposed are either to have the UAS and UAC > construct > > > the Route differently (as is done in the current bis), else > > Jo's text > > > here where this information is carried somehow as > > parameters. I think > > > this is a big hack, and quite a pain. When a proxy receives a > > > re-INVITE, it will have a hard time knowing which direction the > > > re-INVITE is going, and consequently, which of the pieces > of info to > > > extract for processing purposes. > > > > > > The proxy should look at the To and the From to tell direction, > > instead of doing this ugly hack! [1] > > > > The only note then is that if a UA calls itself through a > > Record-Route'ing outbound proxy, then the tags it inserts had > > better be > > different. [I think you've heard that argument before!] > > > > > > Still, bis shouldn't talk about any of this. Keep the spec really > > simple, and let proxies which need to keep state figure out how to > > record-route to their advantage. Jo's text is pretty much on > > the mark. > > > > > > [1] Or, it can always just look at which address is at the > > end of the > > Route... Regardless, your suggestion is an ugly hack. > > Billy, I prefer to hold list discussions based on technical > issues rather > than name calling. > > Proxies route based on request URIs. I'll say it again. > Proxies route based > on request URIs. As such, it is really important that the request URI, > without needing to examine the To/From, by itself, indicate > the resource to > whom the request is targeted. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 22 23:07:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14388 for ; Wed, 22 Nov 2000 23:07:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0002E444B1; Wed, 22 Nov 2000 22:07:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 428264449C for ; Wed, 22 Nov 2000 22:06:52 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 20:06:49 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning G. Schulzrinne'" , Billy Biggs Cc: SIP List Subject: RE: [SIP] Deprecate Early Media MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 22 Nov 2000 20:06:45 -0800 > > A related question is whether any SIP implementations actually handle > early media. It seems harmless to have in pure IP systems, if it gets > never exercised by gateways. > Henning, you should be able to get this information from the SIP bake off registrations, right? From previous bakeoffs, I remember there is usually a number of companies with which early media can be tested. Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 04:32:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02518 for ; Thu, 23 Nov 2000 04:32:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2CDB544339; Thu, 23 Nov 2000 03:32:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 5ED1444336 for ; Thu, 23 Nov 2000 03:31:03 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 23 Nov 2000 09:30:56 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA01866; Thu, 23 Nov 2000 10:29:28 +0100 (BST) From: "Jo Hornsby" To: "Arun Kumar Chippada" , Subject: RE: [SIP] Help with sip Message-ID: <004701c0552f$e091f6a0$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: Thu, 23 Nov 2000 09:29:28 -0000 Content-Transfer-Encoding: 7bit > We want to know whether it is possible to run a SIP Proxy Server and a > SIP User Agent on the same machine. Has anyone ever tried to do this? Yes -- it is possible. In general they are going to have to listen on different ports. (I say in general because its possible to have an application that functions as a UA for one transaction, and a Proxy for another.) - 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 Nov 23 04:51:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08466 for ; Thu, 23 Nov 2000 04:51:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6271044348; Thu, 23 Nov 2000 03:51:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from michelangelo.lostwax.com (unknown [195.224.151.254]) by lists.bell-labs.com (Postfix) with ESMTP id 7C5D644336 for ; Thu, 23 Nov 2000 03:50:21 -0500 (EST) Received: by MICHELANGELO with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 09:47:56 -0000 Message-ID: From: Paul Duncan To: sip@lists.bell-labs.com Subject: RE: [SIP] Help with sip MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 23 Nov 2000 09:47:55 -0000 Hi, Do any of you have any experience of the DynamicSoft SIP user agent? -Paul To iterate is human, to recurse divine. - L. Peter Deutsch (author of Ghostscript) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 05:25: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 FAA20774 for ; Thu, 23 Nov 2000 05:25:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88CC244352; Thu, 23 Nov 2000 04:25:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 1C02944336 for ; Thu, 23 Nov 2000 04:24:37 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 23 Nov 2000 10:24:30 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA19677; Thu, 23 Nov 2000 11:23:01 +0100 (BST) From: "Jo Hornsby" To: "Jonathan Rosenberg" , Cc: , Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <004801c05537$5be63670$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: Thu, 23 Nov 2000 10:23:01 -0000 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Before we begin writing new text, Ah, but I finally got you to bite. &;) > else Jo's text here where this information is carried somehow as > parameters. I think this is a big hack, and quite a pain. I feel this is a little unfair; ultimately, I specified very little about the Request-URI that the proxy inserted, beyond it being a globally reachable address for the proxy. It was only a motivational item and the examples at the end that suggested using a parameter to indicate the original Request-URI. > When a proxy receives a re-INVITE, it will have a hard time > knowing which direction the re-INVITE is going, and > consequently, which of the pieces of info to extract for > processing purposes. As Billy pointed out, making this determination isn't too difficult. > When a request arrives, and a proxy record-routes, it places a > URI into the RR which identifies the *calling UA* as a resource > on this proxy. This URI can be derived from the Contact/From, > but should not be exactly equal to it. This must be a SIP URL. > THe UAS copies the RR set into the response. It also constructs > a Route header by taking the RR's in order, and adding the > Contact from the INVITE at the end. Now, here's the trick. As > the response traverses the proxies, any proxy that record-routed, > finds its RR entry, and *replaces it* with a new URI; this URI > identifies the called party at this server. Probably this is > the request URI that was originally received in the INVITE. > The UAC then constructs the Route as defined in rfc2543. Very nice -- it's cool that you've found a way to maintain "the Request-URI points to the ultimate destination" as an invariant. So instead of: Each Record-Route header field contains a globally reachable SIP URL that identifies a proxy server. Any proxy that wishes to remain in the signalling path of a call leg adds its own SIP URL to the beginning of the list of these fields. This SIP URL MUST represent an address that is reachable via UDP. Requests between both user agents involved in the call leg, in either direction, traverse this route. how about: Each Record-Route header field contains a globally reachable SIP URL that identifies a proxy server. Any proxy that wishes to remain in the signalling path of a call leg adds its own SIP URL to the beginning of the list of these fields in a request. This SIP URL MUST represent an address that is reachable via UDP, and SHOULD represent the calling UA (i.e., be derived from the Contact/From). In addition, a proxy SHOULD modify its URL in the corresponding response(s) to reflect the called UA (i.e., be derived from the original Request-URI). Requests between both user agents involved in the call leg, in either direction, traverse this route. could also perhaps add some motivational text indicating how this behaviour helps to maintain the Request-URI semantic invariant. Moving on, I wrote: > > > > *** Should we remove this bit about 401 and 484? It makes things > > more complicated, and also what if a proxy has collected a load > > of WWW-Authenticate and Proxy-Authenticate headers into a > > 401 (Section 12.4 of bis2) -- the Record-Route could be > > arbitrary. [and] > > *** I haven't said initial INVITE here, since wasn't there > > some talk about abstracting it for, say SUBSCRIBE/NOTIFY > > purposes? [and] > > *** If no Contact, should add the From? Now that we've got the overall operation sorted out &:), does anybody have anything to contribute with regards to these points? Please? &:) 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 Nov 23 05:50:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00907 for ; Thu, 23 Nov 2000 05:50:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7ADFD4435C; Thu, 23 Nov 2000 04:50:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by lists.bell-labs.com (Postfix) with ESMTP id A4ED144346 for ; Thu, 23 Nov 2000 04:49:46 -0500 (EST) Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 23 Nov 2000 12:49:24 +0200 Message-ID: From: Markus.Isomaki@nokia.com To: Billy_Biggs@3com.com, BMoloney@sonusnet.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Registration Question MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 23 Nov 2000 12:48:44 +0200 Hi, In 3GPP (third generation mobile networks standardisation) the situation is that a UA always has an outbound proxy, who's address is learned using DHCP (or some other methods). If the user is roaming, this proxy is located in the visited network, and can offer local services (911 etc.) In addition each user has a "Serving proxy" (in 3GPP terminology Serving Call State Control Function, S-CSCF), which is always situated in his home network/domain. This proxy performs service control for both outgoing and incoming sessions. So, each outgoing INVITE (actually any request) from a user first traverses the outbound proxy and then the "serving proxy", which then decides what to do with the request based on service control: UA--->Outboud proxy (visited nw)--->Serving proxy (home nw)---> The serving proxy is assigned dynamically to the user during registration, e.g. using a 3xx response to REGISTER. The reason might be different service control preferences/capabilities or just load balancing. The problem is the routing of requests from the outbound proxy (visited nw) to serving proxy (home nw). Basically, the outbound proxy can check the user's domain name in From: field and route the request to (some proxy in) the correct home domain. In the home network a database lookup (or SIP redirect) would then be used to determine which S-CSCF is currently allocated to the user and forward the request there. (This is analogous to what happens with incoming requests to the user in the home domain - S-CSCF is located by a database query.) UA--->Outbound proxy--->"Home domain proxy"--->DB lookup--->Serving proxy However, there is a need to optimize the flow by allowing UA or the outbound proxy to know the serving proxy's address directly. This could be done during the registration. The serving proxy's address would need to be carried in the 200 response to REGISTER, so that Outbound proxy and UA are able to learn it. So the request routing would be directly: UA--->Outbound proxy--->serving proxy In my understanding SIP does not support this at the moment, so there have been discussions whether to use Record-Route or some new header. So, there would actually be some use for what Bill Moloney was asking, at least in mobile networks. Rgs, Markus Billy Biggs: > Moloney, Bill (BMoloney@sonusnet.com): > > > I have a question on registration - > > [...] > > I believe that I could accomplish this by having B respond to the > > registration with a 301 Moved Permanently, including a > Contact header > > for C in the response.) > > > > The question is this: Does this redirection only impact future > > registration requests, or does it impact all future > requests - such as > > INVITE? > > The redirection only impacts the specific registration > transaction and > (optionally) future registration transactions. > > Requests such as INVITE go to their destination directly, and have > nothing to do with the registration. > > > What I am trying to accomplish is to have A direct all of its future > > requests (not just registration) to the new proxy server > (C). Will the > > redirect that I mention above accomplish this? > > This is called an outbound proxy, where even though the message is > directed to, say, 'sip:5551212@sip.billybiggs.com', you send > the message > to 'my.local.proxy.com' which then forwards it on. > > The outbound proxy is configured directly on the SIP end > device, or it > can receive it from DHCP. There is no way to signal using REGISTER or > whatever that the proxy should be used as an outbound proxy, nor would > it make sense to provide such signalling. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 06:27:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15661 for ; Thu, 23 Nov 2000 06:27:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C105344346; Thu, 23 Nov 2000 05:27:09 -0500 (EST) 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 4EB6A44336 for ; Thu, 23 Nov 2000 05:26:58 -0500 (EST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA07298; Thu, 23 Nov 2000 12:26:18 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA12970; Thu, 23 Nov 2000 12:26:45 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 12:26:44 +0100 Message-ID: <15A0F4D7BF4DD411BD4C0008C71E2F280D72A3@MCHH233E> From: Tan Ya-Ching To: "'Jonathan Rosenberg'" , "'Henning G. Schulzrinne'" Cc: "'sip@lists.bell-labs.com'" Subject: [SIP] Inviting users to join a centralized conference 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: Thu, 23 Nov 2000 12:26:41 +0100 Hi, In your I-D draft-rosenberg-sip-conferencing-models-00, you omitted to mention the possibility of inviting a user to join a centralized conference by sending the SIP REFER to the conference server. i.e. If user A wishes to invite user B to join, A could send the conference server a REFER : REFER sip:conference34@servers.com SIP/2.0 From: sip:A@example.com To: sip:conference34@servers.com Refer-To: sip:B@example.com The conference server can then decide whether to send an INVITE to user B depending on some criteria (eg. the number of participants, current resources, etc). In this way, we can avoid ringing user B if say the conference is already full. Was this omission intentional ? Ya-Ching Tan ________________________________________________________ ICM N MC MI E7 Tel.: +49 89 722 36147 Hofmannstr. 51 Email: ya-ching.tan@icn.siemens.de 81359 Munich Germany _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 07:17:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01240 for ; Thu, 23 Nov 2000 07:17:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBEBC44364; Thu, 23 Nov 2000 06:17:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 9C5E444336 for ; Thu, 23 Nov 2000 06:16:55 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XKW3X2F3; Thu, 23 Nov 2000 13:14:17 +0100 From: "Hisham Khartabil" 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.50.4133.2400 Subject: [SIP] minor error in section 11.4 of bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 23 Nov 2000 14:17:53 +0200 Content-Transfer-Encoding: 7bit Section 11.4 states in the third bullet point about determining the network destination and request-uri: "Otherwise, if the UAC is configured with the address of an outbound proxy server, the UAC sends the request there. The Request-URI contains the same URL as the To header field if the UAC is the callee. It copies the URL and To header field from the caller's From header if the UAC is the callee." I believe the second sentence should say "The Request-URI contains the same URL as the To header field if the UAC is the calleR". Regards, Hisham Khartabil Hotsip Finland www.hotsip.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 Nov 23 07:40:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08289 for ; Thu, 23 Nov 2000 07:40:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE3D444372; Thu, 23 Nov 2000 06:40:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 20A8744336 for ; Thu, 23 Nov 2000 06:39:47 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 04:39:44 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 23 Nov 2000 04:39:35 -0800 Hi Jo, > Very nice -- it's cool that you've found a way to maintain > "the Request-URI points to the ultimate destination" as an > invariant. I still don't see how this is the case. You just have two different URL's located at the proxy server. I don't see they point to the ultimate destination (unless I missing something fundamental). > Each Record-Route header field contains a globally reachable SIP URL > that identifies a proxy server. Any proxy that wishes to remain in > the signalling path of a call leg adds its own SIP URL to the > beginning of the list of these fields in a request. This SIP URL > MUST represent an address that is reachable via UDP, and SHOULD > represent the calling UA (i.e., be derived from the Contact/From). As above, I don't understand how it "represents" the UA in any sense outside the proxy's internal implementation. I am not saying that this is a bad idea but I do think this wording will cause a lot of confusion. Do you derive it from the just the user part of the Contact/From ? What if the user name is the same (jack@A <-> jack@B?)? Are you suggestign we put an escaped copy of the whole Contact/From into the username portion of the Route ? Why not just say "This SIP URL MUST represent an address that is reachable via UDP, and the user portion SHOULD be distinguishable by the proxy as being destined for the calling UA. The URL SHOULD also be distguishable from any previous Record-Route entries added by the proxy (e.g., due to spiraling routes)." > In addition, a proxy SHOULD modify its URL in the corresponding > response(s) to reflect the called UA (i.e., be derived from the > original Request-URI). Requests between both user agents > involved in the call leg, in either direction, traverse this route. > could also perhaps add some motivational text indicating how this > behaviour helps to maintain the Request-URI semantic invariant. > > > > *** Should we remove this bit about 401 and 484? It makes things > > > more complicated, and also what if a proxy has > collected a load > > > of WWW-Authenticate and Proxy-Authenticate headers into a > > > 401 (Section 12.4 of bis2) -- the Record-Route could be > > > arbitrary. I have no opinion on this one. > > > *** I haven't said initial INVITE here, since wasn't there > > > some talk about abstracting it for, say SUBSCRIBE/NOTIFY > > > purposes? I agree that we need to make the "pre- initial INVITE" behaviour very clear because in mind the descriptions in Sections 11 & 12 are not so clear on this. > > > *** If no Contact, should add the From? Is there a reason why we should change the existing behaviour ? Cheers, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 09:54:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09889 for ; Thu, 23 Nov 2000 09:54:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4265E4436B; Thu, 23 Nov 2000 08:54:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id E9CBE44336 for ; Thu, 23 Nov 2000 08:53:25 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 23 Nov 2000 14:53:19 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA10100; Thu, 23 Nov 2000 15:51:49 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , "Jonathan Rosenberg" Cc: Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <005301c0555c$e8c57220$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: Thu, 23 Nov 2000 14:51:49 -0000 Content-Transfer-Encoding: 7bit Robert Fairlie-Cuninghame wrote: > > Very nice -- it's cool that you've found a way to maintain > > "the Request-URI points to the ultimate destination" as an > > invariant. > > I still don't see how this is the case. You just have two different > URL's located at the proxy server. I don't see they point to the > ultimate destination (unless I missing something fundamental). They might not point to the ultimate destination, per se; but the Request-URI will be meaningful enough to the proxy such that it could reapply its initial routing decisions, if necessary. > > Each Record-Route header field contains a globally reachable SIP URL > > that identifies a proxy server. Any proxy that wishes to remain in > > the signalling path of a call leg adds its own SIP URL to the > > beginning of the list of these fields in a request. This SIP URL > > MUST represent an address that is reachable via UDP, and SHOULD > > represent the calling UA (i.e., be derived from the Contact/From). > > As above, I don't understand how it "represents" the UA in any > sense outside the proxy's internal implementation. I am not saying > that this is a bad idea but I do think this wording will cause a > lot of confusion. I see what you're saying -- my wording is confusing upon reading it back. Hmmm... > Do you derive it from the just the user part of the Contact/From ? > What if the user name is the same (jack@A <-> jack@B?)? Are you > suggestign we put an escaped copy of the whole Contact/From into > the username portion of the Route ? This is probably what I would do, in fact. > Why not just say > > "This SIP URL MUST represent an address that is reachable via UDP, and the > user portion SHOULD be distinguishable by the proxy as being destined for > the calling UA. The URL SHOULD also be distguishable from any previous > Record-Route entries added by the proxy (e.g., due to spiraling routes)." Basically because I'd rather we imply as little as possible about the format of this URL; however, I think we're getting warmer. How about: This SIP URL MUST represent an address that is reachable via UDP, and SHOULD somehow be meaningful to the proxy, such that it could map the URL back to the calling UA (e.g., by embedding the Contact/From ha a parameter). ? > > > > *** If no Contact, should add the From? > > Is there a reason why we should change the existing behaviour ? I wasn't sure what the existing behaviour was... - 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 Nov 23 10:21: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 KAA18380 for ; Thu, 23 Nov 2000 10:21:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DCAC44434D; Thu, 23 Nov 2000 09:21:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from fepB.post.tele.dk (fepB.post.tele.dk [195.41.46.145]) by lists.bell-labs.com (Postfix) with ESMTP id EC7B244336 for ; Thu, 23 Nov 2000 09:20:38 -0500 (EST) Received: from dynamicsoft.com ([195.249.119.171]) by fepB.post.tele.dk (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001123152030.QCLQ2411.fepB.post.tele.dk@dynamicsoft.com>; Thu, 23 Nov 2000 16:20:30 +0100 Message-ID: <3A1D35E4.6BD0A4B8@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Jo Hornsby'" , hgs@cs.columbia.edu, sip@lists.bell-labs.com, Billy_Biggs@3com.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 23 Nov 2000 16:21:08 +0100 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Before we begin writing new text, lets look at the sub-problems and build up > a solution. I have another possibility that may be the best of all worlds. > I'll start with Roberts list: > > 1. non SIP URLs in request URI > > We can either define record-route parameters, or else make sure that the URL > put into the record route is a sip url. I originally propose RR parameters, > but I think insisting on a SIP URL is backwards compatible and more > reasonable. That seems to be consensus. > > 2. transaction ID in the reverse direction > > This was the problem that if there was a spiral in the forward direction, > and the current bis approach was used by the UAS to construct the Route > header, a request would arrive twice at the spiraled-at proxy. These could > be identified as separate transactions (as a result of Via header > differences), but there is no way to determine which of the two iterations > through it is. > > The solution is that the request URI need some info that the proxy created > and is returned to it. There seems to be little disagreement on that. > > 3. Proxy doesn't see URI parameters it inserted in RR, returned to it in > request URI > > This is a consequence of the current bis text for building the route. > Proposed solution for this component is that the construction process at the > UAS has to copy the URI parameters from the RR rather than the Contact/From. > > 4. detecting new behavior > > I don't think this is an issue, since we need a solution thats backwards > compatible. > > 5. (this one is my own) The request URI should refer to the resource for > whom the message is destined > > The solutions proposed are either to have the UAS and UAC construct the > Route differently (as is done in the current bis), else Jo's text here where > this information is carried somehow as parameters. I think this is a big > hack, and quite a pain. When a proxy receives a re-INVITE, it will have a > hard time knowing which direction the re-INVITE is going, and consequently, > which of the pieces of info to extract for processing purposes. > > Putting it all together, its clear from (1) that the record routes must > always be SIP URLs. From 2 and 3, at least the parameters placed into the RR > should be copied into the Route by both sides, and from 5, the URI should > contain information that identifies the recipient of the message, different > in both directions. > > My new proposal does all of the above, and requires no mangling of RR in the > UA. Here's how it goes. > > When a request arrives, and a proxy record-routes, it places a URI into the > RR which identifies the *calling UA* as a resource on this proxy. This URI > can be derived from the Contact/From, but should not be exactly equal to it. > This must be a SIP URL. THe UAS copies the RR set into the response. It also > constructs a Route header by taking the RR's in order, and adding the > Contact from the INVITE at the end. Now, here's the trick. As the response > traverses the proxies, any proxy that record-routed, finds its RR entry, and > *replaces it* with a new URI; this URI identifies the called party at this > server. Probably this is the request URI that was originally received in the > INVITE. The UAC then constructs the Route as defined in rfc2543. Like Robert I struggle with this RR URI which "identifies the [caller/callee] as a resource on this proxy". In the typical case only one of the two parties would be known in any meaningful way to the proxy. The proxy record-routes using its own SIP URL and can derive a user name from the caller/callee but they won't necessraily mean anything to it, and it wouldn't necessarily be able to route messages on it (and it won't have to - that's what the Route is for). This means [5] isn't really satisfied anyway. > ... > This is similar to Jo's proposal but maintains the property that a request > from A to B has a URI that always points to a resource that gets routed to > B, and vice a versa (in Jo's case, the URI is the same in both directions). > Thus, I think it satisfies everyone. Note that maddr is no longer needed so > long as the host port gets routed back to the same server; of course it can > put maddr if it likes. > > The drawback is that the proxy needs to do a bit more work. Not a lot, > though. Well, until now proxies just had to pop the top Via and forward the response, with this proposal they have to decode some or all Record-Route headers, figure out which one it generated itself and modify it. It might be tempting for proxy writers NOT to put a user part into its own Record-Route headers to begin with. That way there's less work on the return path and routing works exactly the same. Alternatively, as has also been suggested, proxies can put whatever private state they like in there and just consider it a piece of state which identifies the call to that proxy. It seems to me that Jonathans and Jo's proposals degenerate to the same approach: always use SIP URLs in Record-Route and not make any assumptions what goes into the user part. Anders _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 10: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 KAA24630 for ; Thu, 23 Nov 2000 10:41:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D855844357; Thu, 23 Nov 2000 09:41:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BA5914434F for ; Thu, 23 Nov 2000 09:40:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA02767; Thu, 23 Nov 2000 10:42:58 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 10:38:45 -0500 Message-ID: From: Jonathan Rosenberg To: "'Paul.Duncan@LOSTWAX.COM'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Help with sip 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: Thu, 23 Nov 2000 10:38:35 -0500 I do :) -Jonathan R. --- Jonathan Rosenberg dynamicsoft jdrosen@dynamicsoft.com -----Original Message----- From: Paul Duncan To: sip@lists.bell-labs.com Sent: Thu Nov 23 04:47:55 2000 Subject: RE: [SIP] Help with sip Hi, Do any of you have any experience of the DynamicSoft SIP user agent? -Paul To iterate is human, to recurse divine. - L. Peter Deutsch (author of Ghostscript) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com 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 Nov 23 11:44:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19394 for ; Thu, 23 Nov 2000 11:44:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 36D484433C; Thu, 23 Nov 2000 10:44:08 -0500 (EST) 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 3A21044336 for ; Thu, 23 Nov 2000 10:43:46 -0500 (EST) Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id LAA18075; Thu, 23 Nov 2000 11:43:23 -0500 (EST) Message-ID: <3A1D492A.C5FCE6BF@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil Cc: sip@lists.bell-labs.com Subject: Re: [SIP] minor error in section 11.4 of bis 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, 23 Nov 2000 11:43:22 -0500 Content-Transfer-Encoding: 7bit The section was somewhat confusing, so I rewrote it for the next edition. Hisham Khartabil wrote: > > Section 11.4 states in the third bullet point about determining the network > destination and request-uri: > > "Otherwise, if the UAC is configured with the address of an outbound proxy > server, the UAC sends > the request there. The Request-URI contains the same URL as the To header > field if the UAC is the > callee. It copies the URL and To header field from the caller's From header > if the UAC is the callee." > > I believe the second sentence should say "The Request-URI contains the same > URL as the To header field if the UAC is the calleR". _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 14: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 OAA11494 for ; Thu, 23 Nov 2000 14:20:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3ADE44369; Thu, 23 Nov 2000 13:20:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sargasso.cse.msu.edu (sargasso.cse.msu.edu [35.9.20.10]) by lists.bell-labs.com (Postfix) with ESMTP id 63CCC44336 for ; Thu, 23 Nov 2000 13:19:24 -0500 (EST) Received: from arctic.cse.msu.edu (arctic.cse.msu.edu [35.9.20.20]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with ESMTP id OAA24094; Thu, 23 Nov 2000 14:19:14 -0500 (EST) From: Arun Kumar Chippada To: Jo Hornsby Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Help with sip In-Reply-To: <004701c0552f$e091f6a0$4e34c3c1@ubiquity.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 23 Nov 2000 14:19:14 -0500 (EST) We are running the SIP Proxy Server and the SIP User Agent on the same machine. We are using the Columbia University's sipd as our proxy server and their sipua as the user agent. The sipd is listening on the default port 5060. The sipua is started on port 5444. We verified that they are listening properly like this on 2 different ports using "netstat -a" Then we tried to register a user with user name "chippada" and domain name "cse.msu.edu" sending the register request from the sipua to sipd. The machine that we are running the sipd as well as the sipua has IP address "10.0.0.16" and name "johan.cse.msu.edu" So we have the following session using the sipua and the output printed by the sipua. sipua> register sip:chippada@cse.msu.edu sip:10.0.0.16 Registering to server as sip:chippada@cse.msu.edu at sip:10.0.0.16 with contact sip:chippada@johan.cse.msu.edu:5444 REGISTER sip:10.0.0.16 SIP/2.0 Via: SIP/2.0/UDP johan.cse.msu.edu:5444; branch=4044117737-0 From: sip:chippada@cse.msu.edu To: sip:chippada@cse.msu.edu CSeq: 1 REGISTER Call-ID: 4163501107@johan.cse.msu.edu Expires: 3600 Contact: sip:chippada@johan.cse.msu.edu:5444 Content-Length: 0 975005101.235 ReceiveUDP(): received UDP packet (length 299) from 10.0.0.16:1052: SIP/2.0 482 Loop detected Via: SIP/2.0/UDP johan.cse.msu.edu:5444; branch=4044117737-0 From: sip:chippada@cse.msu.edu To: sip:chippada@cse.msu.edu Call-ID: 4163501107@johan.cse.msu.edu Cseq: 1 REGISTER Date: Thu, 23 Nov 2000 18:45:01 GMT Server: Columbia-SIP-Server/1.0 Content-Length: 0 We are thinking that the sipua is able to contact the sipd but the sipd is not registering the user and instead sending the message "Loop Detected". Does this have to do something with running the user agent and the proxy server on the same machine? Or are we doing something wrong in the register request? Thankyou, Arun. On Thu, 23 Nov 2000, Jo Hornsby wrote: > > We want to know whether it is possible to run a SIP Proxy Server and a > > SIP User Agent on the same machine. Has anyone ever tried to do this? > > Yes -- it is possible. In general they are going to have to listen > on different ports. (I say in general because its possible to have an > application that functions as a UA for one transaction, and a > Proxy for another.) > > > - 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 Nov 23 14:30:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15619 for ; Thu, 23 Nov 2000 14:30:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F10484437E; Thu, 23 Nov 2000 13:30:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id ABC8F4437A for ; Thu, 23 Nov 2000 13:29:38 -0500 (EST) 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 OAA10378; Thu, 23 Nov 2000 14:29:31 -0500 (EST) Received: from localhost (kns10@localhost) by cisalpino.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA26150; Thu, 23 Nov 2000 14:29:30 -0500 (EST) From: Kundan Singh To: Arun Kumar Chippada Cc: Subject: RE: [SIP] Help with sip 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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 23 Nov 2000 14:29:30 -0500 (EST) Hi Arun, We have found and fixed this problem a couple of weeks ago. I will directly contact you soon regarding the new version. Also, please do not use the SIP list for discussion related to a specific implementation. -- Kundan Singh http://www.cs.columbia.edu/~kns10 On Thu, 23 Nov 2000, Arun Kumar Chippada wrote: > We are running the SIP Proxy Server and the SIP User Agent on the same > machine. We are using the Columbia University's sipd as our proxy server > and their sipua as the user agent. The sipd is listening on the default > port 5060. The sipua is started on port 5444. We verified that they are > listening properly like this on 2 different ports using "netstat -a" > > Then we tried to register a user with user name "chippada" and domain > name "cse.msu.edu" sending the register request from the sipua to > sipd. The machine that we are running the sipd as well as the sipua has IP > address "10.0.0.16" and name "johan.cse.msu.edu" > > So we have the following session using the sipua and the output printed by > the sipua. > > > > sipua> register sip:chippada@cse.msu.edu sip:10.0.0.16 > Registering to server as sip:chippada@cse.msu.edu at sip:10.0.0.16 with > contact sip:chippada@johan.cse.msu.edu:5444 > REGISTER sip:10.0.0.16 SIP/2.0 > Via: SIP/2.0/UDP johan.cse.msu.edu:5444; branch=4044117737-0 > From: sip:chippada@cse.msu.edu > To: sip:chippada@cse.msu.edu > CSeq: 1 REGISTER > Call-ID: 4163501107@johan.cse.msu.edu > Expires: 3600 > Contact: sip:chippada@johan.cse.msu.edu:5444 > Content-Length: 0 > > > 975005101.235 ReceiveUDP(): received UDP packet (length 299) from > 10.0.0.16:1052: > SIP/2.0 482 Loop detected > Via: SIP/2.0/UDP johan.cse.msu.edu:5444; branch=4044117737-0 > From: sip:chippada@cse.msu.edu > To: sip:chippada@cse.msu.edu > Call-ID: 4163501107@johan.cse.msu.edu > Cseq: 1 REGISTER > Date: Thu, 23 Nov 2000 18:45:01 GMT > Server: Columbia-SIP-Server/1.0 > Content-Length: 0 > > We are thinking that the sipua is able to contact the sipd but the sipd is > not registering the user and instead sending the message "Loop Detected". > Does this have to do something with running the user agent and the > proxy server on the same machine? Or are we doing something wrong in the > register request? > > Thankyou, > Arun. > > > > On Thu, 23 Nov 2000, Jo Hornsby wrote: > > > > We want to know whether it is possible to run a SIP Proxy Server and a > > > SIP User Agent on the same machine. Has anyone ever tried to do this? > > > > Yes -- it is possible. In general they are going to have to listen > > on different ports. (I say in general because its possible to have an > > application that functions as a UA for one transaction, and a > > Proxy for another.) > > > > > > - 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 Thu Nov 23 15:12:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03071 for ; Thu, 23 Nov 2000 15:12:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 519D744356; Thu, 23 Nov 2000 14:12:09 -0500 (EST) 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 7A4E844336 for ; Thu, 23 Nov 2000 14:11:47 -0500 (EST) Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id PAA25206 for ; Thu, 23 Nov 2000 15:11:34 -0500 (EST) Message-ID: <3A1D79F4.5113CB98@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Calling oneself Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 23 Nov 2000 15:11:32 -0500 Content-Transfer-Encoding: 7bit I'm not sure, but it seems that there's a simple fix: simply have the UA create *different* tags depending on whether this is for a From or To. However, the tag is constant across calls. The general matching rule is - match incoming requests so that the To matches the locally generated tag and the From matches the tag generated by the other side Modifying the running example to use tag=5 for the To tag > I decide to call myself. I create a call-leg struct to represent it. > Let's call it "Line 1". I send out the initial INVITE: > > [From Line 1] > INVITE sip:me@proxy > Via: SIP/2.0/UDP my.ip > To: > From: ;tag=7 > Call-ID: 5 > > This eventually loops back to me. Now I see coming in: > > INVITE sip:me@proxy > Via: SIP/2.0/UDP some.ip > To: > From: ;tag=7 > Call-ID: 5 > > I check and see there is no To-tag, so this is a new incoming call. I > create a call struct to represent it, called "Line 2". Line 2 now > begins ringing. I respond with a 180 and the user switches lines and > answers the incoming call: > > [From Line 2] > SIP/2.0 200 OK > Via: SIP/2.0/UDP some.ip > To: ;tag=5 Modification here. > From: ;tag=7 > Call-ID: 5 > > When I receive this response, I find the related pending transaction. > Arguably, I could first find which call-leg it is destined to (and > immediately have a problem), but say that I do transaction mapping first > so we don't break yet. I match the OK and send an ACK: > > [From Line 1] > ACK sip:me@contactaddr > Via: SIP/2.0/UDP my.ip > To: ;tag=5 > From: ;tag=7 > Call-ID: 5 > > At which point the other pending transaction also correctly matches > this ACK to it. > > Now, on Line 2, I decide to hang up. I've had enough of talking to > myself. So, I send a BYE: > As usuall, the callee simply flips To and From. > [From Line 2] > BYE sip:me@contact.addr > Via: SIP/2.0/UDP my.ip > To: ;tag=7 > From: ;tag=5 > Call-ID: 5 > > I now see this incoming BYE: > > BYE sip:me@contact.addr > Via: SIP/2.0/UDP some.ip > To: ;tag=7 > From: ;tag=5 > Call-ID: 5 > Using the rule above, it matches the call on line 1, since 7 is the locally-generated tag (stuck into From). > > Using unique tags per call avoids any confusion even in this case, and > also protects the UA against clients which always use the same tag and > happen to make two calls with the same Call-ID. Since both Line1 and Line2 have the same call-ID (one incoming and one outgoing), they would have the same locally generated tag according to your rule, so I don't see how this helps. Two calls with the same call-id can't happen, by definition. If they do, the implementation is broken (and would presumably generate the "wrong" tag, too, while it is at it). _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 16:15: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 QAA28856 for ; Thu, 23 Nov 2000 16:15:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E1C54436A; Thu, 23 Nov 2000 15:15:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AB3B744336 for ; Thu, 23 Nov 2000 15:14:23 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA03293; Thu, 23 Nov 2000 16:09:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 16:04:57 -0500 Message-ID: From: Jonathan Rosenberg To: "'Tan Ya-Ching'" , Jonathan Rosenberg , "'Henning G. Schulzrinne'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Inviting users to join a centralized conference 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, 23 Nov 2000 16:04:47 -0500 No, the omission was not intentional, and can be done as well. I can include in the next version of the document. -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: Tan Ya-Ching [mailto:Ya-Ching.Tan@icn.siemens.de] > Sent: Thursday, November 23, 2000 6:27 AM > To: 'Jonathan Rosenberg'; 'Henning G. Schulzrinne' > Cc: 'sip@lists.bell-labs.com' > Subject: [SIP] Inviting users to join a centralized conference > > > Hi, > > In your I-D draft-rosenberg-sip-conferencing-models-00, you > omitted to mention the possibility of inviting a user to join > a centralized conference by sending the SIP REFER to the > conference server. i.e. If user A wishes to invite user B to > join, A could send the conference server a REFER : > > REFER sip:conference34@servers.com SIP/2.0 > From: sip:A@example.com > To: sip:conference34@servers.com > Refer-To: sip:B@example.com > > The conference server can then decide whether to send an > INVITE to user B depending on some criteria (eg. the number > of participants, current resources, etc). In this way, we can > avoid ringing user B if say the conference is already full. > > Was this omission intentional ? > > Ya-Ching Tan > ________________________________________________________ > ICM N MC MI E7 Tel.: +49 89 722 36147 > Hofmannstr. 51 Email: ya-ching.tan@icn.siemens.de > 81359 Munich > Germany > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 16:30:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05016 for ; Thu, 23 Nov 2000 16:30:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1286E44376; Thu, 23 Nov 2000 15:30:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7EB9C44373 for ; Thu, 23 Nov 2000 15:29:24 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA03345; Thu, 23 Nov 2000 16:31:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 16:27:27 -0500 Message-ID: From: Jonathan Rosenberg To: Anders Kristensen , Jonathan Rosenberg Cc: "'Jo Hornsby'" , hgs@cs.columbia.edu, sip@lists.bell-labs.com, Billy_Biggs@3com.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 23 Nov 2000 16:27:23 -0500 > -----Original Message----- > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > Sent: Thursday, November 23, 2000 10:21 AM > To: Jonathan Rosenberg > Cc: 'Jo Hornsby'; hgs@cs.columbia.edu; sip@lists.bell-labs.com; > Billy_Biggs@3com.com > Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) > > > Like Robert I struggle with this RR URI which "identifies the > [caller/callee] as a resource on this proxy". In the typical case only > one of the two parties would be known in any meaningful way to the > proxy. The proxy record-routes using its own SIP URL and can derive a > user name from the caller/callee but they won't necessraily mean > anything to it, and it wouldn't necessarily be able to route > messages on > it (and it won't have to - that's what the Route is for). > This means [5] > isn't really satisfied anyway. My initial posting was not sufficiently detailed to explain this, so let me clarify. The URL inserted into the request must be something that (1) given the client follows the server location process in draft-ietf-sip-srv-00, causes the URL to be resolved to an address/port on the proxy, and (2) is a URL that, if received by the proxy, the routing logic in the proxy would cause the request to be forwarded to the Contact/From address of the calling party. Similarly, the URL in the response must be something that (1) routes to the proxy, and (2) is a URL whose routing logic in the proxy would cause the request to be forwarded to the Contact/From address of the called party. Since we don't dictate routing behavior, so too would the format of these URLs not be specified. So, if we assume the caller is A@originating.com, and the called party is B@terminating.com, one choice for the URL pair (request, response) is: (A@originating.com;maddr=proxy, B@terminating.com;maddr=proxy) this tuple results in the same Route set getting constructed as gets constructed by the current bis mechanism. The tuple satisfies the first mandated property since the maddr causes the routing to go to the proxy. The second is satisfied for any proxy that always forwards requests not in its domain to the domain the R-URI, and for the originating.com proxy, knows how to find A, and for terminating, knows how to find B. Now, another way to structure the pair, that the terminating proxy could use, is: (A%64originating.com@server12.terminating.com, B@server12.terminating.com) assuming its routing policy was that if the domain was its own, and the user in the R-URI is unknown, the R-URI is URL-decoded. If it contains an @, the resulting URL is used as the new request URI. Now, consider the case of a proxy that has some kind of call state or something, and a spiral comes through it, and it needs to differentiate each pass through the spiral. In this case, the two tuples it could use are: (A@originating.com;maddr=proxy;sessionid=76599, B@terminating.com;maddr=proxy;sessionid=76599) (A@originating.com;maddr=proxy;sessionid=876, B@terminating.com;maddr=proxy;sessionid=876) This satisfies that problem raised on the list with state and spirals. Robert asked: >Additionally, if the proxy is keeping full call state, eg based on unique >Call-Id. Is it REQUIRED to mess with the Record-Route in the response. >Otherwise, adding a simple I think yes, since otherwise we won't achieve this property of the request URI referring to a resource that would cause the request to be routed to the appropriate party. Now, things won't break if the proxies don't do this, but they become more brittle, and various other subtle things might happen down the road. I had come up with some other scenario where this property was needed, but don't recall when it was. -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 Nov 23 17:18: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 RAA24582 for ; Thu, 23 Nov 2000 17:18:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C359844373; Thu, 23 Nov 2000 16:18:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by lists.bell-labs.com (Postfix) with ESMTP id C6FD844336 for ; Thu, 23 Nov 2000 16:17:13 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id OAA25698 for lists.bell-labs.com!sip; Thu, 23 Nov 2000 14:17:04 -0800 (PST) Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0) id AA01935; Thu, 23 Nov 00 14:50:40 -0800 From: "Bernard Aboba" 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.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] ACTION REQUESTED: Call for nominations for IAB/IESG Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 23 Nov 2000 14:11:12 -0800 Content-Transfer-Encoding: 7bit The 2000 Nominations Committee is now soliciting nominations for the open slots on the IESG and IAB. Please take the time, even if it is only a few moments, to send us your thoughts. Members of the community are encouraged to nominate candidates for any of the positions which are up for re-filling: IESG Terms ending in March, 2001: Fred Baker IETF Chair Scott Bradner Transport Randy Bush Operations & Management Patrik Faltstrom Applications Thomas Narten Internet Dave Oran Routing Jeff Schiller Security IAB Terms ending in March, 2001: Harald Alvestrand Ran Atkinson Rob Austein Steve Deering Tony Hain Geoff Huston Members of the community are encouraged to contact the nomcom to nominate someone for any of these positions, to provide input relating to potential candidates, or to provide comments regarding the past performance of incumbents, which will be considered during the deliberations of the nominating committee. Comments sent to the nominations committee will be kept in confidence. As noted in RFC 2727 "all deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential." Self-nominations are accepted. The deadline for nominations is midnight Monday, December 18, 2000. Early input is desirable so that candidates may be interviewed during IETF 49. The members of the NomCom can be contacted individually at the addresses below or collectively at nomcom@ietf.org. Additionally, the members of the NomCom will be identified at the IETF by a marker (as yet undetermined) on their name tags. People are encouraged to take advantage of the opportunity to talk to the members of the NomCom about nominations and other issues related to the IAB and IESG membership. The 2000 Nominations Committee Phil Roberts Stuart Cheshire Perry E. Metzger Bill Woodcock Hadriel Kaplan Alain Durand Vijay Srinivasan Hal Sandick David Robinson David Allan Non-voting members: Bernard Aboba (Chair) Avri Doria (Past Chair) Leslie Daigle (IAB liason) Allison Mankin (IESG liason) The role of non-voting members (from RFC 2727) The nominations committee comprises at least a non-voting Chair, 10 voting volunteers, and 3 non-voting liaisons. The sitting IAB and IESG members each appoint a non-voting liaison to the nominating committee from their current membership who are not sitting in an open position. The Chair of the prior year's nominating committee also serves as a non-voting liaison. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 20:35: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 UAA06687 for ; Thu, 23 Nov 2000 20:35:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BAA444341; Thu, 23 Nov 2000 19:35:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id B4CFA44336 for ; Thu, 23 Nov 2000 19:34:51 -0500 (EST) Received: from nist.gov (IDENT:mranga@jitterbug.antd.nist.gov [129.6.55.8]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id UAA11818; Thu, 23 Nov 2000 20:28:00 -0500 (EST) Message-ID: <3A1DC4BD.533272E6@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.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: Erik Nissen , jainsip@Sun.COM, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A16922C.EFDE9019@ericsson.com> <3A1A5BAC.A0975580@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------4924906B84991ECB3D6FBCBE" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 23 Nov 2000 20:30:37 -0500 --------------4924906B84991ECB3D6FBCBE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Chris, Erik, While we are on the subject of Exceptions, why do null arguments throw runtime exceptions when you do a get on them? For example, in the Accept interface, getContentSubtype throws a IllegalArgumentException if is null. IMHO, I think it is valid to have a null subtype so why not just return null rather than throw exception here? I don't quite follow the argument that lazy parsing "necessitates throwing a parse exception for all get methods". Here is what I had envisioned: 1 When a message comes in it will be separated into headers based on type. 2 The header would be returned with no field initialized except the text corresponding to the message. (this would necessitate examining the first few bytes of the message to determine the header type but the rest remains unparsed.) You can also stow away the type information in the Header that is returned as well to know which parser rule to invoke later. 3. Later, when the application wants to parse the header, it has the string corresponding to the message and can hand it off to the parser, which can then fill in the appropriate fields corresponding to the header. 4. Subsequently, the application can access the fields just as an eager parser based application would do. ( Where am I missing the boat with this? ) It appears that what is being attempted here (please correct me if I am wrong) is to use exceptions as a mechanism to catch un-initialized fields so the parser can be invoked in the exception handler perhaps. This leads to a lot of overhead in clunky code. I think it is a mistake to throw exceptions on every get to try to protect the application from inadvertently accessing fields that have not been initialized. Why not just assume that the application must be smart enough to parse the header text before accessing fields and not try to provide a complex mechanism as above? Regards, Ranga. Chris Harris wrote: > Erik, > > The implication of what you say is that all set methods in the header > interfaces which take String arguments must throw a checked > JainSipParseException. I think this is reasonable given that different > implementations will be more tolerant than others. However, in order to allow > lazy parsing by an implementation, all get methods in the header interfaces > (regardless of return type) must throw a checked parse exception. This is a > lot of checked exceptions - and will make life more awkward for the > application developer. It would certainly be much less effort to not allow > lazy parsing - there would be no need to throw a parse exception for all get > methods - greatly reducing the number of checked exceptions. Unfortunately it > has been said that JAIN SIP support for lazy parsing is a must. If it is then > I guess there is no other choice than to include the exceptions? > > Regards, > Chris > > Erik Nissen wrote: > > > Chris Harris wrote: > > > > > > > > We need to decide whether this should be a checked or runtime exception. > > > > The rule of thumb is to use: > > * checked exceptions when the program should handle situations which > > can/will occur. > > * runtime exceptions when there are programming error (God forbid :-) > > > > So: > > Parse errors should throw checked exceptions. > > Becaurse parse errors are outside the control of the programmer > > and he/she should be forced to handle such conditions in the code. > > > > Null/wrong arguments should throw runtime exceptions. > > > > If it is possible, reduce the number of methods throwing (checked) > > exceptions > > to a minimum. > > > > Best regards, > > /Erik Nissen, > > Ericsson Utveckling AB > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------4924906B84991ECB3D6FBCBE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Chris, Erik,

While we are on the subject of Exceptions, why do null arguments throw runtime exceptions when you do a get on them? For example, in the Accept interface, getContentSubtype throws a IllegalArgumentException if  is null. IMHO, I think it is valid to have a null subtype so why not just return null rather than throw exception here?

I don't quite follow the argument that lazy parsing  "necessitates throwing a parse exception for all get methods".   Here is what I had envisioned:
 

1 When a message comes in it will be separated into headers based on type.
2 The header would be returned with no field initialized except the text corresponding to the message. (this would necessitate examining the first few bytes of the message to determine the header type but the rest remains unparsed.) You can also stow away the type information in the Header that is returned as well to know which parser rule to invoke later.
3. Later, when the application wants to parse the header, it has the string corresponding to the message and can hand it off to the parser, which can then fill in the appropriate fields corresponding to the header.
4. Subsequently, the application can access the fields just as an eager parser based application would do.

( Where am I missing the boat with this? )

It appears that what is being attempted here (please correct me if I am wrong) is to use exceptions as a mechanism to catch un-initialized fields so the parser can be invoked in the exception handler perhaps. This leads to a lot of overhead in clunky code. I think it is a mistake to throw exceptions on every get to try to protect the application from inadvertently accessing fields that have not been initialized.  Why not just assume that the application must be smart enough to parse the header text before accessing fields and not try to provide a complex mechanism as above?
 

Regards,

Ranga.

Chris Harris wrote:

Erik,

The implication of what you say is that all set methods in the header
interfaces which take String arguments must throw a checked
JainSipParseException. I think this is reasonable given that different
implementations will be more tolerant than others. However, in order to allow
lazy parsing by an implementation, all get methods in the header interfaces
(regardless of return type) must throw a checked parse exception. This is a
lot of checked exceptions - and will make life more awkward for the
application developer. It would certainly be much less effort to not allow
lazy parsing - there would be no need to throw a parse exception for all get
methods - greatly reducing the number of checked exceptions. Unfortunately it
has been said that JAIN SIP support for lazy parsing is a must. If it is then
I guess there is no other choice than to include the exceptions?

Regards,
Chris

Erik Nissen wrote:

> Chris Harris wrote:
>
> >
> > We need to decide whether this should be a checked or runtime exception.
>
> The rule of thumb is to use:
> * checked exceptions when the program should handle situations which
> can/will occur.
> * runtime exceptions when there are programming error (God forbid :-)
>
> So:
> Parse errors should throw checked exceptions.
> Becaurse parse errors are outside the control of the programmer
> and he/she should be forced to handle such conditions in the code.
>
> Null/wrong arguments should throw runtime exceptions.
>
> If it is possible, reduce the number of methods throwing (checked)
> exceptions
> to a minimum.
>
> Best regards,
> /Erik Nissen,
> Ericsson Utveckling AB

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

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------4924906B84991ECB3D6FBCBE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 21: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 SMTP id VAA15550 for ; Thu, 23 Nov 2000 21:04:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF7114437B; Thu, 23 Nov 2000 20:04:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id E72A24437A for ; Thu, 23 Nov 2000 20:03:38 -0500 (EST) Received: from nist.gov (IDENT:mranga@jitterbug.antd.nist.gov [129.6.55.8]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id UAA12072; Thu, 23 Nov 2000 20:58:33 -0500 (EST) Message-ID: <3A1DCBE5.76C21E7D@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.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/alternative; boundary="------------EC1C8FE2489E5998A164B1DD" Subject: [SIP] Multiple headers of a given 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: Thu, 23 Nov 2000 21:01:09 -0500 --------------EC1C8FE2489E5998A164B1DD Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Hello! This is a rather simple question. Of all the SIP headers in the bis document, which can appear multiple times in a Request / Response ? (For example, VIA can appear multiple times, ACCEPT can appear multiple times etc. but FROM can appear only once and TO can appear only once. ) If there is a table in the document giving this information I have missed, please let me know (and apologies for redundant mail). Thanks. Regards Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------EC1C8FE2489E5998A164B1DD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello!

This is a rather simple question. Of all the SIP headers in the bis document, which can appear multiple times in a Request / Response ?  (For example,  VIA can appear multiple times, ACCEPT can appear multiple times etc. but FROM can appear only once and TO can appear only once. ) If there is a table in the document giving this information  I have missed,  please let me know (and apologies for redundant mail).

Thanks.

Regards

Ranga. 

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------EC1C8FE2489E5998A164B1DD-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 23 21: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 VAA24480 for ; Thu, 23 Nov 2000 21:33:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B19A4437A; Thu, 23 Nov 2000 20:33:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 478BD44336 for ; Thu, 23 Nov 2000 20:32:13 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA03648; Thu, 23 Nov 2000 21:34:20 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 21:30:07 -0500 Message-ID: From: Jonathan Rosenberg To: "'mranga@nist.gov'" , sip@lists.bell-labs.com Subject: RE: [SIP] Multiple headers of a given type. 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, 23 Nov 2000 21:29:58 -0500 Since a comma separated list of values (indicated in BNF with #) is identical to multiple headers of the same name, any header whose BNF starts with # can appear more than once. -Jonathan R. -----Original Message----- >From: M. Ranganathan [mailto:mranga@nist.gov] >Sent: Thursday, November 23, 2000 9:01 PM >To: sip@lists.bell-labs.com >Subject: [SIP] Multiple headers of a given type. > > >Hello! >This is a rather simple question. Of all the SIP headers in the bis document, which can >appear multiple times in a Request / Response ? (For example, VIA can appear multiple >times, ACCEPT can appear multiple times etc. but FROM can appear only once and TO can >appear only once. ) If there is a table in the document giving this information I have >missed, please let me know (and apologies for redundant mail). >Thanks. >Regards >Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --- 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 Nov 23 22:39:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11027 for ; Thu, 23 Nov 2000 22:39:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B2A5B44385; Thu, 23 Nov 2000 21:39:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5D2C544336 for ; Thu, 23 Nov 2000 21:38:53 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA03730; Thu, 23 Nov 2000 22:41:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 22:36:57 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , Robert Sparks Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Possible REFER problem? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 23 Nov 2000 22:36:47 -0500 Sorry for the delay in picking this thread up... I'm trying to finish a rev on Caller Prefs, and there are some issues here. First off, Eric raised a problem with my proposed solution. I'm replicating it here since its been a while: > If you remember, the problem was when doing call transfer > with consultation > with the REFER request, how can we make sure that the INVITE > request (from > the Transferee to the Transfer Target) is going to reach the > exact same > User-Agent as the one that was consulted by the Transferor. > > The solution was to use the header "Accept-Contact" and > specify the contact > of the transfer target. > > I was taking a look at the caller preferences extension, thinking that > "Accept-Contact" had solved our problem, but I think it does > not solves the > problem. > > Suppose we have the following participants: > > Transferor (Tror) > - Sip address: sip:tror@acme.com > - Current location: sip:tror@office1.acme.com > > Transferee (Tree) > - Sip address: sip:tree@acme.com > - Current location: sip:tree@office1.acme.com > > Transfer-Target (TT) > - Sip address: sip:tt@acme.com > - Current location: sip:tt@office4.mediatrix.com > > > Tror and Tree have established calls. Tror contacts TT and > ask if he wishes > to accept the call, which he does. Tror sends the following > REFER to Tree: > > REFER sip:tree@office1.acme.com SIP/2.0 > From: sip:tror@acme.com > To: sip:tree@acme.com > Refer-To: sip:tt@acme.com?Accept-Contact=sip:tt@office4.mediatrix.com > ... > > Which spawns the INVITE from Tree to a proxy server somewhere in ACME. > > INVITE sip:tt@acme.com SIP/2.0 > From: sip:tree@acme.com > To: sip:tt@acme.com > Accept-Contact=sip:tt@office4.mediatrix.com > Referred-By: ... > ... > > > The proxy receives this request and checks with the location > server to find > where can tt@acme.com be found. The list of contact returned > could look > like the following: > > Contact: sip:tt@office1.acme.com > Contact: sip:tt@mediatrix.com > Contact: sip:assistant@office1.acme.com > > Now the proxy has these 3 contacts that do not match the > Accept-Contact URL, > although the proxy at mediatrix.com would translate > tt@mediatrix.com to > tt@office4.mediatrix.com. Now the proxy does not really know > which contact > is prefeered, and can try any of the three contacts, and > someone can happily > answer at those addresses. > > How can we avoid this? > > First, I think that the Proxy should send the Accept-Contact in its > downstream requests, in order to have the downstream proxies > be able to use > the same mechanism. But in truth, the proxy does not know if > the downstream > request is going to be sent to a proxy or to a UA, so it is > possible for a > UA to receive such a request. Would it be a good idea to > have the UA take a > look at the Accept-Contact header to know if the request is > really for him? > I think that the current caller preferences draft states that > a UA should > ignore these header if it receives it. Eric is correct that even if none of the registered contacts matches those in the Accept-Contact header, a proxy will forward the request, with Accept-Contact intact. As a result, the request may ultimately arrive at several UAs that don't match. Another related problem is that Accept-Contact is not specified as a filter-all-but rule (partly for the reasons Eric observes; a request would never get past the first proxy since the Contact might be known only at a later proxy). The caller preferences specification has a process for combining the q values. At best, it would effect ordering of a sequential search. What we need here is a mechanism that says, "I only want to talk to you if you are one of these Contacts". This rule can ONLY be enforced in the UAs. This capability does not exist in the current caller preferences draft. However, I think it will prove useful here (actually, it really is needed for call transfer, more on that below), and other places too. So, I will add an Accept-Only-Contact header to caller preferences, with this header only being used by a UA. Now, on to some other issues. Consider the scenario of A talking to B. A calls C, and then A wishes to transfer B to C, making sure that B gets the same instance of C that A was talking to. Adam asked, why not have A refer B to the Contact obtained from C: > At the risk of sounding daft, I don't see why using the "Contact:" > header as the new "INVITE" URI is considered Evil in this case. > > When explaining the difference between, say, the "From:" (or "To:") > field and the "Contact:" field, I generally think of "From:"/"To:" as > being the persistent URI for contacting the appropriate resource in > an abstract sense (by resource, I mean "Adam Roach" or > "helpdesk staffer" > or "sales representative"), while the "Contact:" URI > indicates "where to > get to me (as a particular instance of that resource) on this > particular > device at this particular moment." The answer is that URIs most definitely have a context; a place from which they can be usefully used. In a perfect world with no NATs, firewalls, or devices that want to know whats going on within the network, it would work dandy. But thats not reality. The classic example is an ACD application, where help@helpdesk.com can be routed to a variety of agents (agent32@host32.helpdesk.com). Sophisticated software tracks the call status of the various agents, how much volume they get, etc. Incoming calls MUST come in through this helpdesk proxy to work. The proxy always record routes. In fact, to enforce this, the proxy has access to a hosts file with the host32.helpdesk.com address mapped to an IP address. Outside of this proxy, that hostname is unroutable. So, if A called B, and then A called C, and C was one of these operators, the URI returned by C (agent32@host32.helpdesk.com) will definitely not be useful for B to use directly. Another issue was raised about the possibility of per-call Contacts generated dynamically by a UA. Yikes. I don't know any UA that does this. Unfortunately, if a UA provides no consistent form of identification to the network or other users, it can't expect to be consistently transferred to in this case. So, I think we can punt this case and declare it as "don't do this". Robert had proposed a hybrid approach: > Given all that, and the likelyhood that for many (if not > most) instances, the contact provided in the Contact URL > _is_ routable, what problems exist with taking the following > approach? > > 1) REFER B directly to the contact that C provided to A. > 2) If it fails, REFER B to C's well known URL with an Accept-Contact > header containing the contact that C provided to A. > Hmm. Turns out you can construct cases where neither (1) nor (2) will work. What if, when A called C, it wasn't really C that was called, but some time-of-day routed 800 number that got forwarded to C. Now, while A talks to C, the logic for the forwarding changes. Now, when A sends a REFER to B, the URI in the Refer-To is that 800 number. It never even comes close to being sent to a single UA that matches the Accept-Contact header. In this scenario, sending directly to the Contact won't work either, since the operator is not directly callable. Don't you love feature interaction problems ;) ? So, basically, referring to exactly the same person I'm talking to is hard because (1) their unique address may not be directly routable, and (2) the logic used to get to that person from a directly routable address may change. If you ignore (1), you come up with the solution to (2) of sending to the Contact. If you ignore (2), you come up with the Accept-Only-Contact solution to deal with (1). If you want to deal with both (1) and (2), its really rough. I thought about having A also include Route headers as header params to the URI in the Refer-To, but this doesn't work either. A route header set usable from A may not be usable from B, for many reasons, not the least of which is problem (1) once more. Perhaps these cases are so extreme its not worth worrying about. I wouldn't be surprised if they don't work in the PSTN either. So, despite its complexity, I feel compelled to recommend that Robert's hybrid approach be described in the REFER specification as the preferred way to do transfer out of consultation, along with a nice long explanation of why it needs to be so. I'm not sure about the order though. I suspect that (2) will work in far more cases than (1) will. I welcome better ideas if anyone has any... 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 Nov 23 22:53: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 WAA15273 for ; Thu, 23 Nov 2000 22:53:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7A153443AD; Thu, 23 Nov 2000 21:53:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id A2138443A7 for ; Thu, 23 Nov 2000 21:52:32 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 19:52:31 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" Cc: "'Jo Hornsby'" , sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 23 Nov 2000 19:52:28 -0800 Hi Jonathan, > > Since we don't dictate routing behavior, so too would the > format of these > URLs not be specified. So, if we assume the caller is > A@originating.com, and > the called party is B@terminating.com, one choice for the URL > pair (request, > response) is: So you are saying that the Record-Route SHOULD at least contain the user@host portions of the Contact or Request-URI in some form or another. We should _suggest_ a method for acheiving this. For SIP URL's, I think the first method (below) is the best for sustaining your protocol invariant property. > > (A@originating.com;maddr=proxy, B@terminating.com;maddr=proxy) > The second method (inserting an escaped URL) is probably best recommended when you are forced to construct a Record-ROute header from a non-SIP URL (for generality). > > (A%64originating.com@server12.terminating.com, > B@server12.terminating.com) > Don't you mean (sip%3aA%64originating.com@proxy, sip%3aB%64server12.terminating.com@proxy) ?? If not, why not ? [I added the "sip:" to a) better identify the escaped URL (rather than just relying on the "@") and b) to differeniate non-SIP URL's which may not have a "@" eg (tel%3a555-1234@proxy)] Is it worthwhile suggesting different methods for SIP and non-SIP URL's ? Or KISS and just stick with the latter, more general method? 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 Thu Nov 23 23:11: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 XAA20730 for ; Thu, 23 Nov 2000 23:11:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6661744384; Thu, 23 Nov 2000 22:11:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id D6BDF44336 for ; Thu, 23 Nov 2000 22:10:41 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 20:10:41 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 23 Nov 2000 20:10:40 -0800 I think we also need to clarify the use of angle brackets in the Record-Route header. They may interfere with the inclusion on the route parameters in the Request-URI (which cannot use angle brackets). Eg, Record-Route: ;rstate=253878954375364 is "correct" but will probably cause problems in some proxies/UA's as only the base url (<...>) will be copied into the Request-URI. I think the best suggestion for proxies is to either a) not to use angle brackets in Record-Route hoeaders or b) include all record-route parameters inside the angle brackets. The latter is more general (KISS) but is a slight bending of the definition of "record-route parameters". However, the parameters _are_ being treated as URL parameters in the Request-URI so the behaviour makes sense from that respect. Agree? Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Thursday, November 23, 2000 10:52 PM > To: Fairlie-Cuninghame, Robert; Jonathan Rosenberg > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) > > > Robert Fairlie-Cuninghame wrote: > > > Very nice -- it's cool that you've found a way to maintain > > > "the Request-URI points to the ultimate destination" as an > > > invariant. > > > > I still don't see how this is the case. You just have two different > > URL's located at the proxy server. I don't see they point to the > > ultimate destination (unless I missing something fundamental). > > They might not point to the ultimate destination, per se; but > the Request-URI will be meaningful enough to the proxy such > that it could reapply its initial routing decisions, if > necessary. > > > > Each Record-Route header field contains a globally > reachable SIP URL > > > that identifies a proxy server. Any proxy that wishes > to remain in > > > the signalling path of a call leg adds its own SIP URL to the > > > beginning of the list of these fields in a request. This SIP URL > > > MUST represent an address that is reachable via UDP, and SHOULD > > > represent the calling UA (i.e., be derived from the > Contact/From). > > > > As above, I don't understand how it "represents" the UA in any > > sense outside the proxy's internal implementation. I am not saying > > that this is a bad idea but I do think this wording will cause a > > lot of confusion. > > I see what you're saying -- my wording is confusing upon reading > it back. Hmmm... > > > Do you derive it from the just the user part of the Contact/From ? > > What if the user name is the same (jack@A <-> jack@B?)? Are you > > suggestign we put an escaped copy of the whole Contact/From into > > the username portion of the Route ? > > This is probably what I would do, in fact. > > > Why not just say > > > > "This SIP URL MUST represent an address that is reachable > via UDP, and the > > user portion SHOULD be distinguishable by the proxy as > being destined for > > the calling UA. The URL SHOULD also be distguishable from > any previous > > Record-Route entries added by the proxy (e.g., due to > spiraling routes)." > > Basically because I'd rather we imply as little as possible about > the format of this URL; however, I think we're getting warmer. > > How about: > This SIP URL MUST represent an address that is reachable via > UDP, and SHOULD somehow be meaningful to the proxy, such that > it could map the URL back to the calling UA (e.g., by embedding > the Contact/From ha a parameter). > ? > > > > > > *** If no Contact, should add the From? > > > > Is there a reason why we should change the existing behaviour ? > > I wasn't sure what the existing behaviour was... > > > - Jo. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 24 02:45:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18700 for ; Fri, 24 Nov 2000 02:45:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3B88444397; Fri, 24 Nov 2000 01:45:10 -0500 (EST) 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 2E5CC44336 for ; Fri, 24 Nov 2000 01:44:08 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Nov 24 02:42:01 EST 2000 Received: by lists.bell-labs.com (Postfix) id 705D544380; Fri, 24 Nov 2000 02:28:52 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from netuk01.uk.lucent.com (netuk01.uk.lucent.com [135.86.77.12]) by lists.bell-labs.com (Postfix) with ESMTP id BE09E4437D for ; Fri, 24 Nov 2000 02:28:51 -0500 (EST) Received: by netuk01.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Fri, 24 Nov 2000 07:24:07 -0000 Message-ID: From: "Hartrey, Mike" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] How to unsubscribe Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 24 Nov 2000 07:23:56 -0000 Can anyone help me to unsubscribe from the list. I've sent 'unsubscribe' emails to the listserv but they fail. I contacted the list administrator and no response - so as a last resort I'm having to send to the list. Ideas? Thanks, _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 24 04:17: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 EAA18075 for ; Fri, 24 Nov 2000 04:17:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3BFFE44351; Fri, 24 Nov 2000 03:17:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id A8C314433A for ; Fri, 24 Nov 2000 03:16:05 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Nov 2000 01:16:01 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Neil Deason'" Cc: Sip List Subject: RE: [SIP] More Torture Test Messages Available MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 24 Nov 2000 01:15:50 -0800 Hi Neil, > "Fairlie-Cuninghame, Robert" wrote: > > > > The colon in the user part of Test 36 (the long telephone > subscriber) needs > > to be quoted. Perhaps you could also put a similar long > telephone-subscriber > > URL in the Contact - this would test whether the URL was correctly > > reproduced if the call is accepted. > > I think the ':' might be OK as it becomes part of a hname in > an escaped header as it follows a '?', i.e. from parsing it > into: > %22Route:%20X%40Y%3bZ = W%22@gw1.wcom.com;user=phone > header = hvalue > However this would then mean the following ';' and '=' in the > hvalue need to be escaped. No, this is not an escaped SIP header (per se), rather it is all just part of a telephone subscriber user portion and as such it follows a different set of rules. Reread Section 2. You need to escape any characters that not in the unreserved or user-unreserved sets (hname and hvalue have nothing to do with it). Colon is such a character. > Also we would back into the problem of escaped headers not being > allowed in Request-URIs. I am a bit uncertain about this now. > The spec indicates that they are not allowed (Table 2) and > should be removed by a proxy before futher processing (4.3). > However there seems to be a feeling that this may not be > desirable > - should there be a spec change here? Again, these are not escaped headers but merely part of the user part, they are only inpreterpreted with respect to the tel: URL syntax and not the SIP URL syntax. I hope that clarifies things. 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 Nov 24 04:36:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24095 for ; Fri, 24 Nov 2000 04:36:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B5C8443A5; Fri, 24 Nov 2000 03:36:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 3BA6D44399 for ; Fri, 24 Nov 2000 03:35:28 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 24 Nov 2000 09:35:21 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA20936; Fri, 24 Nov 2000 10:33:54 +0100 (BST) Message-ID: <3A1E3601.98FF4798@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: "Fairlie-Cuninghame, Robert" Cc: Sip List Subject: Re: [SIP] More Torture Test Messages Available References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 24 Nov 2000 09:33:53 +0000 Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > Hi Neil, > > > "Fairlie-Cuninghame, Robert" wrote: > > > > > > The colon in the user part of Test 36 (the long telephone > > subscriber) needs > > > to be quoted. Perhaps you could also put a similar long > > telephone-subscriber > > > URL in the Contact - this would test whether the URL was correctly > > > reproduced if the call is accepted. > > > > I think the ':' might be OK as it becomes part of a hname in > > an escaped header as it follows a '?', i.e. from parsing it > > into: > > %22Route:%20X%40Y%3bZ = W%22@gw1.wcom.com;user=phone > > header = hvalue > > However this would then mean the following ';' and '=' in the > > hvalue need to be escaped. > > No, this is not an escaped SIP header (per se), rather it is all just part > of a telephone subscriber user portion and as such it follows a different > set of rules. Ooops I missed that rather important point, I'll change ':' -> %3a. Thanks, 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 Nov 24 05:33: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 FAA12270 for ; Fri, 24 Nov 2000 05:33:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57C2444366; Fri, 24 Nov 2000 04:33:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 76CAB44363 for ; Fri, 24 Nov 2000 04:32:34 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 24 Nov 2000 10:32:27 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA15208; Fri, 24 Nov 2000 11:30:58 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , "'Jonathan Rosenberg'" Cc: Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <006101c05601$a21dc570$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 24 Nov 2000 10:30:58 -0000 Content-Transfer-Encoding: 7bit Robert Fairlie-Cuninghame wrote: > > Jonathan Rosenberg wrote: > > > Since we don't dictate routing behavior, so too would the > > format of these URLs not be specified. So, if we assume the > > caller is A@originating.com, and the called party is > > B@terminating.com, one choice for the URL pair (request, > > response) is: > > So you are saying that the Record-Route SHOULD at least contain the > user@host portions of the Contact or Request-URI in some form or > another. We should _suggest_ a method for acheiving this. For > SIP URL's, I think the first method (below) is the best for > sustaining your protocol invariant property. > > > > (A@originating.com;maddr=proxy, B@terminating.com;maddr=proxy) > > It works as long as the Request-URI doesn't already have an maddr parameter. &:) > The second method (inserting an escaped URL) is probably best recommended > when you are forced to construct a Record-ROute header from a non-SIP URL > (for generality). > > > > (A%64originating.com@server12.terminating.com, > > B@server12.terminating.com) > > > Don't you mean > > (sip%3aA%64originating.com@proxy, > sip%3aB%64server12.terminating.com@proxy) > ?? > > If not, why not ? > > [I added the "sip:" to a) better identify the escaped URL (rather > than just relying on the "@") and b) to differeniate non-SIP URL's > which may not have a "@" eg (tel%3a555-1234@proxy)] > > Is it worthwhile suggesting different methods for SIP and non-SIP > URL's ? Or KISS and just stick with the latter, more general method? I would KISS. &:) Personally, I prefer the embed-the-uri-as-a-parameter method, but that's probably mainly for aesthetical reasons (on simple URLs, one needs no escaping at all). One plus for parameters (although I guess the user part could still be used, but...) that I just thought of allows proxy to insert all the necessary information in the request only. Say I (a machine in sipfarm.net) receive the following: INVITE sip:buffy@sunnydale-high.edu SIP/2.0 From: sip:willow@sunnydale-high.edu;tag=2718281828 To: sip:buffy@sunnydale-high.edu Contact: sip:willow@machine35.cyber-cafe.com ... I Record-Route and proxy downstream (illegal line wrapping for clarity): INVITE sip:angel@sunnydale.com SIP/2.0 From: sip:willow@sunnydale-high.edu;tag=2718281828 To: sip:buffy@sunnydale-high.edu Contact: sip:willow@machine35.cyber-cafe.com Record-Route: ... At some point later, I see a re-INVITE: INVITE sip:sipfarm.net; caller=sip:willow@machine35.cyber-cafe.com; callee=sip:buffy@sunnydale-high.edu SIP/2.0 From: sip:buffy@sunnydale-high.edu;tag=3141592654 To: sip:willow@sunnydale-high.edu;tag=2718281828 Route: sip:willow@machine35.cyber-cafe.com ... Looking at the From and To, I can determine that this is from called to caller. Granted, it's a little more work initially, and potentially in subsequent requests (because of the From/To decision), but it seems a little easier than inspecting and modifying Record-Routes in any responses. 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 Fri Nov 24 06:11: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 GAA24342 for ; Fri, 24 Nov 2000 06:11:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5584C443A6; Fri, 24 Nov 2000 05:11:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id E863B4436C for ; Fri, 24 Nov 2000 05:10:28 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 24 Nov 2000 11:10:21 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA01201; Fri, 24 Nov 2000 12:08:53 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , "Jonathan Rosenberg" Cc: Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <006301c05606$edeb57b0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 24 Nov 2000 11:08:52 -0000 Content-Transfer-Encoding: 7bit Robert Fairlie-Cuninghame wrote: > I think we also need to clarify the use of angle brackets in the > Record-Route header. They may interfere with the inclusion on the route > parameters in the Request-URI (which cannot use angle brackets). Eg, > > Record-Route: ;rstate=253878954375364 > > is "correct" but will probably cause problems in some proxies/UA's as only > the base url (<...>) will be copied into the Request-URI. > > I think the best suggestion for proxies is to either a) not to use angle > brackets in Record-Route hoeaders or b) include all record-route > parameters inside the angle brackets. > > The latter is more general (KISS) but is a slight bending of the > definition of "record-route parameters". Indeed. &:) > However, the parameters > _are_ being treated as URL parameters in the Request-URI so the > behaviour makes sense from that respect. I'm not quite with you here, but I think I agree. As things currently stand, it doesn't look like Record-Route parameters are particularly useful; however, this doesn't mean we won't think of some funky new use in the future. Therefore, at the moment, it might be wise to note that proxies probably always want to use angle brackets. Just to be sure. 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 Nov 24 06:20:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27191 for ; Fri, 24 Nov 2000 06:20:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8A4D443D1; Fri, 24 Nov 2000 05:20:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id DAD01443CC for ; Fri, 24 Nov 2000 05:19:14 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Nov 2000 03:19:15 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , "'Jonathan Rosenberg'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 24 Nov 2000 03:19:05 -0800 Jo, > > > > > > (A@originating.com;maddr=proxy, B@terminating.com;maddr=proxy) > > > > It works as long as the Request-URI doesn't already have an > maddr parameter. &:) > Request-URI's can't have maddr parameters but yes for the callee's Contact this might be an issue. > > The second method (inserting an escaped URL) is probably > best recommended > > when you are forced to construct a Record-ROute header from > a non-SIP URL > > (for generality). > > > > > (sip%3aA%64originating.com@proxy, > > sip%3aB%64server12.terminating.com@proxy) > > ?? > > > > One plus for parameters (although I guess the user part could > still be used, but...) that I just thought of allows proxy to > insert all the necessary information in the request only. Say > I (a machine in sipfarm.net) receive the following: There will also be problems when the URL contains escaped characters that have significance in the original URL (eg @,=,;). You have no way of telling why the character was escaped. In my opinion this is the sort of thing that makes a behaviour brittle, eg, if the proxy actually relies on correctly recovering the original uri for routing purposes. [so yes a parameter is better in my view as well). > > INVITE sip:buffy@sunnydale-high.edu SIP/2.0 > From: sip:willow@sunnydale-high.edu;tag=2718281828 > To: sip:buffy@sunnydale-high.edu > Contact: sip:willow@machine35.cyber-cafe.com > ... > > I Record-Route and proxy downstream (illegal line wrapping > for clarity): > > INVITE sip:angel@sunnydale.com SIP/2.0 > From: sip:willow@sunnydale-high.edu;tag=2718281828 > To: sip:buffy@sunnydale-high.edu > Contact: sip:willow@machine35.cyber-cafe.com > Record-Route: caller=sip:willow@machine35.cyber-cafe.com; > callee=sip:buffy@sunnydale-high.edu> > ... > > At some point later, I see a re-INVITE: > > INVITE sip:sipfarm.net; > caller=sip:willow@machine35.cyber-cafe.com; > callee=sip:buffy@sunnydale-high.edu SIP/2.0 > From: sip:buffy@sunnydale-high.edu;tag=3141592654 > To: sip:willow@sunnydale-high.edu;tag=2718281828 > Route: sip:willow@machine35.cyber-cafe.com > ... > > Looking at the From and To, I can determine that this is from > called to caller. > > Granted, it's a little more work initially, and potentially > in subsequent requests (because of the From/To decision), but > it seems a little easier than inspecting and modifying > Record-Routes in any responses. Only this doesn't provide you with the original request-uri/Contact if you want to use it for routing purposes (as the caller and callee fields are built up from the To and From). I still maintain that embedding the URI into user part still doesn't represent the calling or called UA's - to everyone else they are just arbitrary user names located at the proxy. So how does that help with the desired invariant property? I beleive using parameters would be better. Eg, placing the following RR header in the forward request Record-Route: and this in the response Record-Route: is much less brittle than trying to embed the URL in the user part. Of course, if the proxy is storing full state then rr-uri is not required. As for maddr handling: If the proxy is required to add the rr-uri parameter, then I think the proxy must also replace any maddr with a "rr-maddr" parameter so that the outgoning request-URI is faithfully recreated. Of course, once again this is only needed if the proxy is not keeping full state. Ie, it is the responsibility of the actual implemenation to reproduce the same routing action. Eg, if your example was instead (with same routing > INVITE sip:buffy@sunnydale-high.edu SIP/2.0 > From: sip:willow@sunnydale-high.edu;tag=2718281828 > To: sip:buffy@sunnydale-high.edu > Contact: sip:willow@cyber-cafe.com;maddr=machine35.cyber-cafe.com;yadda=blah Then I would suggest the following Forward RR could be generated Record-Route: Once again, all we can do is provide a recommendation for proxies not want to keep full state. So all we have to specify in the spec is characteristics of what the base user@host is, right? Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 24 06: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 GAA01046 for ; Fri, 24 Nov 2000 06:32:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 417AF443D0; Fri, 24 Nov 2000 05:32:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id A3D4E44380 for ; Fri, 24 Nov 2000 05:31:44 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Nov 2000 03:31:45 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 24 Nov 2000 03:31:41 -0800 > > > However, the parameters > > _are_ being treated as URL parameters in the Request-URI so the > > behaviour makes sense from that respect. > > I'm not quite with you here, but I think I agree. As things > currently stand, it doesn't look like Record-Route parameters > are particularly useful; however, this doesn't mean we won't > think of some funky new use in the future. Well to any other proxy than the generating/intended proxy, the extra record-route related Request-URI parameters are simply treated as unknown "other-param" parameters (as per Section 2 grammer definitions). Given that record-route parameters (ie, ones copied into the Request-URI) are implementation specific, I think we need to recommend that all parameter names should be of the form "rr-xxxxxx" (or something) so that we don't get collisions in the future between new URL parameters and some proxy's implementation specific record-route parameters. [Record-Route is a peculiar case, as I was saying, because we need to copy the Record-Route parameters in to the Request-URI (which can't include angle brackets).] > Therefore, at the moment, it might be wise to note that > proxies probably always want to use angle brackets. Just to > be sure. > Agreed. Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 24 08:42:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12538 for ; Fri, 24 Nov 2000 08:42:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 430D54436E; Fri, 24 Nov 2000 07:42:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id D0BD344336 for ; Fri, 24 Nov 2000 07:41:17 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 24 Nov 2000 13:41:10 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA21756; Fri, 24 Nov 2000 14:39:42 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , "'Jonathan Rosenberg'" Cc: Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <006501c0561b$ffbaecc0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 24 Nov 2000 13:39:42 -0000 Content-Transfer-Encoding: 7bit Robert wrote: > > > > > > > > (A@originating.com;maddr=proxy, B@terminating.com;maddr=proxy) > > > > > > It works as long as the Request-URI doesn't already have an > > maddr parameter. &:) > > > > Request-URI's can't have maddr parameters but yes for the callee's > Contact this might be an issue. Actually, this is no-longer true: Request-URIs are now allowed to contain maddr; From/To are still not (see bis). > > One plus for parameters (although I guess the user part could > > still be used, but...) that I just thought of allows proxy to > > insert all the necessary information in the request only. Say > > I (a machine in sipfarm.net) receive the following: > > > > INVITE sip:buffy@sunnydale-high.edu SIP/2.0 > > From: sip:willow@sunnydale-high.edu;tag=2718281828 > > To: sip:buffy@sunnydale-high.edu > > Contact: sip:willow@machine35.cyber-cafe.com > > ... > > > > I Record-Route and proxy downstream (illegal line wrapping > > for clarity): > > > > INVITE sip:angel@sunnydale.com SIP/2.0 > > From: sip:willow@sunnydale-high.edu;tag=2718281828 > > To: sip:buffy@sunnydale-high.edu > > Contact: sip:willow@machine35.cyber-cafe.com > > Record-Route: > caller=sip:willow@machine35.cyber-cafe.com; > > callee=sip:buffy@sunnydale-high.edu> > > ... > > > > At some point later, I see a re-INVITE: > > > > INVITE sip:sipfarm.net; > > caller=sip:willow@machine35.cyber-cafe.com; > > callee=sip:buffy@sunnydale-high.edu SIP/2.0 > > From: sip:buffy@sunnydale-high.edu;tag=3141592654 > > To: sip:willow@sunnydale-high.edu;tag=2718281828 > > Route: sip:willow@machine35.cyber-cafe.com > > ... > > > > Looking at the From and To, I can determine that this is from > > called to caller. > > > > Granted, it's a little more work initially, and potentially > > in subsequent requests (because of the From/To decision), but > > it seems a little easier than inspecting and modifying > > Record-Routes in any responses. > > Only this doesn't provide you with the original request-uri/Contact > if you want to use it for routing purposes (as the caller and > callee fields are built up from the To and From). My example was dull. I had actually copied the Contact to the callee parameter, and the Request-URI to the caller parameter; unfortunately, the Request-URI happened to be the same as the To. > I still maintain that embedding the URI into user part still doesn't > represent the calling or called UA's - to everyone else they are just > arbitrary user names located at the proxy. I so don't disagree. Say we have the following scenario: A --- P1 --- P2 --- B Even on the initial INVITE, the Request-URI that P2 sees maybe completely different from Request-URI that that P1 sees (imagine that I'm on holiday and thus I've set up call forwarding to a close friend). Thus from that perspective, an arbitrary Record-Route URI that only makes sense to the proxy that inserted it is no different. > So how does that help with the desired invariant property? I > beleive using parameters would be better. I don't think it matters how the URI is formed, as typically it's only going to make sense to the proxy that inserted it (unless we come up with a BCP, or sommat). I think when I talk about this invariant, I don't necessarily mean that the Request-URI along the entire route would be routable by an arbitrary proxy; what I mean is that the Request-URI would be routable at the salient proxy. I think what Jonathan didn't like -- and I wasn't happy about it, either -- was that in the reverse direction, the Request-URI could in no way ever have been useful in finding the calling UA (save the case that the calling and called UA were the same, perhaps). With the sorts of things being proposed now -- having a different URI on request and response, or somehow embedding the caller, say -- this is no longer the case. Sure, it's likely that only the proxy that inserted the URI will understand it, but that's in no way atypical, and I feel still satisfies the invariant. > As for maddr handling: If the proxy is required to add the rr-uri > parameter, then I think the proxy must also replace any maddr with > a "rr-maddr" parameter so that the outgoning request-URI is > faithfully recreated. I'm not sure why this is needed? Couldn't we just do something like: sip:giles@sunnydale-high.edu;maddr=library.sunnydale-high.edu to sip:proxyfarm.net;caller=sip:giles@sunnydale-high.edu%3B maddr%3Dlibrary.sunnydale-hig.edu Or is there some subtle parsing point that I'm missing? > Once again, all we can do is provide a recommendation for proxies > not want to keep full state. So all we have to specify in the spec is > characteristics of what the base user@host is, right? I don't think we even need a user. - 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 Nov 24 08:58:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17522 for ; Fri, 24 Nov 2000 08:58:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 216BC44392; Fri, 24 Nov 2000 07:58:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 00F0444389 for ; Fri, 24 Nov 2000 07:57:51 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 24 Nov 2000 13:57:44 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA26638; Fri, 24 Nov 2000 14:56:17 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , "Jonathan Rosenberg" Cc: Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <006601c0561e$50b990c0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 24 Nov 2000 13:56:16 -0000 Content-Transfer-Encoding: 7bit > > > However, the parameters > > > _are_ being treated as URL parameters in the Request-URI so the > > > behaviour makes sense from that respect. > > > > I'm not quite with you here, but I think I agree. As things > > currently stand, it doesn't look like Record-Route parameters > > are particularly useful; however, this doesn't mean we won't > > think of some funky new use in the future. > > Well to any other proxy than the generating/intended proxy, the extra > record-route related Request-URI parameters are simply treated as unknown > "other-param" parameters (as per Section 2 grammer definitions). Indeed. > Given that record-route parameters (ie, ones copied into the Request-URI) > are implementation specific, I think we need to recommend that > all parameter names should be of the form "rr-xxxxxx" (or something) > so that we don't get collisions in the future between new URL > parameters and some proxy's implementation specific record-route > parameters. I'm getting slightly confused by the term "record-route parameters", I think. Are you talking about the parameters that a proxy adds to the SIP URL? If the Contact, say, has all the `='s and `;'s escaped, and the result of this is embedded as a parameter, does this solve the collision problem? > [Record-Route is a peculiar case, as I was saying, because we need > to copy the Record-Route parameters in to the Request-URI (which > can't include angle brackets).] I think there's still a need to distinguish between Record-Route parameters (that is, rr-params in section 6.34 of bis02) and the parameters that a proxy adds to the SIP URL that it places in a Record-Route value. Record-Route params might still prove to be useful; they could be used so that a proxy can identify the Record-Route entry that it added, for instance. 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 Nov 24 10:04:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02358 for ; Fri, 24 Nov 2000 10:04:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5180C4433A; Fri, 24 Nov 2000 09:04:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A159B44336 for ; Fri, 24 Nov 2000 09:03:40 -0500 (EST) Received: from dynamicsoft.com (useraa06.ie.uudial.com [212.120.133.7]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA04686; Fri, 24 Nov 2000 10:05:42 -0500 (EST) Message-ID: <3A1E82FB.DA1FC1AC@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: Erik Nissen , jainsip@Sun.COM, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A16922C.EFDE9019@ericsson.com> <3A1A5BAC.A0975580@dynamicsoft.com> <3A1DC4BD.533272E6@nist.gov> Content-Type: multipart/alternative; boundary="------------D57D0BA92715AE252D49E90C" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 24 Nov 2000 15:02:19 +0000 --------------D57D0BA92715AE252D49E90C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ranga, See comments below. Regards, Chris "M. Ranganathan" wrote: > > Chris, Erik, > > While we are on the subject of Exceptions, why do null arguments throw > runtime exceptions when you do a get on them? For example, in the > Accept interface, getContentSubtype throws a IllegalArgumentException > if is null. IMHO, I think it is valid to have a null subtype so why > not just return null rather than throw exception here? By a "doing a get on a null argument" here I assume you mean attempting to get a non-existent optional field? If you do this a checked ParameterNotSetException is thrown, not a runtime exception. There are two approaches to handling optional header parts. One approach is to allow the passing and returning of null objects from get and set methods (implicit "remove" and "has"), and the other is to explicitly add has and remove methods (and exceptions on the set and get methods). As for mandatory header parts - I think passing null to a set method should definitely throw an IllegalArgumentException. (If it is considered acceptable to have a "null" subType then we should make it optional) > > > I don't quite follow the argument that lazy parsing "necessitates > throwing a parse exception for all get methods". Here is what I had > envisioned: > > > 1 When a message comes in it will be separated into headers based on > type. > 2 The header would be returned with no field initialized except the > text corresponding to the message. (this would necessitate examining > the first few bytes of the message to determine the header type but > the rest remains unparsed.) You can also stow away the type > information in the Header that is returned as well to know which > parser rule to invoke later. > 3. Later, when the application wants to parse the header, it has the > string corresponding to the message and can hand it off to the parser, > which can then fill in the appropriate fields corresponding to the > header. > 4. Subsequently, the application can access the fields just as an > eager parser based application would do. > > ( Where am I missing the boat with this? ) An application has no idea whether an implementation is using lazy or eager parsing - it is simply passed a header object - and then if it is interested in a particular field it calls the appropriate get method (which would internally invoke the parser in a lazy parsing implementation). So the application is completely oblivious to whether or not this "optimisation" is used by the implementation. If the field is optional and does not exist in the header a ParameterNotSetException will be thrown by the implementation. If the field is mandatory and does not exist, a JainSipParseException will be thrown (header is malformed). If any header field is malformed a JainSipParseException is thrown. If a JainSipParseException is thrown, this indicates that the application must use the header's getValue method to get a string representation of the header value and do what it can with that. > > > It appears that what is being attempted here (please correct me if I > am wrong) is to use exceptions as a mechanism to catch un-initialized > fields so the parser can be invoked in the exception handler perhaps. > This leads to a lot of overhead in clunky code. I think it is a > mistake to throw exceptions on every get to try to protect the > application from inadvertently accessing fields that have not been > initialized. Why not just assume that the application must be smart > enough to parse the header text before accessing fields and not try to > provide a complex mechanism as above? We are using ParameterNotSetException for the case of an optional header not existing, and a JainSipParseException for the case of a malformed header being received from the network. If we assume the application is smart enough to do all header value parsing, we reduce a header to just being two strings - the type and value, which puts the burden of parsing on an application - this work can be done by the underlying implementation - doesn't it make more sense for an application to catch an exception than have to parse all header value strings (especially since this functionality already exists in the underlying stack) > > > > Regards, > > Ranga. > > Chris Harris wrote: > >> Erik, >> >> The implication of what you say is that all set methods in the >> header >> interfaces which take String arguments must throw a checked >> JainSipParseException. I think this is reasonable given that >> different >> implementations will be more tolerant than others. However, in order >> to allow >> lazy parsing by an implementation, all get methods in the header >> interfaces >> (regardless of return type) must throw a checked parse exception. >> This is a >> lot of checked exceptions - and will make life more awkward for the >> application developer. It would certainly be much less effort to not >> allow >> lazy parsing - there would be no need to throw a parse exception for >> all get >> methods - greatly reducing the number of checked exceptions. >> Unfortunately it >> has been said that JAIN SIP support for lazy parsing is a must. If >> it is then >> I guess there is no other choice than to include the exceptions? >> >> Regards, >> Chris >> >> Erik Nissen wrote: >> >> > Chris Harris wrote: >> > >> > > >> > > We need to decide whether this should be a checked or runtime >> exception. >> > >> > The rule of thumb is to use: >> > * checked exceptions when the program should handle situations >> which >> > can/will occur. >> > * runtime exceptions when there are programming error (God forbid >> :-) >> > >> > So: >> > Parse errors should throw checked exceptions. >> > Becaurse parse errors are outside the control of the programmer >> > and he/she should be forced to handle such conditions in the code. >> >> > >> > Null/wrong arguments should throw runtime exceptions. >> > >> > If it is possible, reduce the number of methods throwing (checked) >> >> > exceptions >> > to a minimum. >> > >> > Best regards, >> > /Erik Nissen, >> > Ericsson Utveckling AB >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > --------------D57D0BA92715AE252D49E90C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ranga,

See comments below.

Regards,
Chris

"M. Ranganathan" wrote:

 
Chris, Erik,

While we are on the subject of Exceptions, why do null arguments throw runtime exceptions when you do a get on them? For example, in the Accept interface, getContentSubtype throws a IllegalArgumentException if  is null. IMHO, I think it is valid to have a null subtype so why not just return null rather than throw exception here?

By a "doing a get on a null argument" here I assume you mean attempting to get a non-existent optional field? If you do this a checked ParameterNotSetException is thrown, not a runtime exception.

There are two approaches to handling optional header parts. One approach is to allow the passing and returning of null objects from get and set methods (implicit "remove" and "has"), and the other is to explicitly add has and remove methods (and exceptions on the set and get methods). As for mandatory header parts - I think passing null to a set method should definitely throw an IllegalArgumentException.

(If it is considered acceptable to have a "null" subType then we should make it optional)

 

I don't quite follow the argument that lazy parsing  "necessitates throwing a parse exception for all get methods".   Here is what I had envisioned:
 

1 When a message comes in it will be separated into headers based on type.
2 The header would be returned with no field initialized except the text corresponding to the message. (this would necessitate examining the first few bytes of the message to determine the header type but the rest remains unparsed.) You can also stow away the type information in the Header that is returned as well to know which parser rule to invoke later.
3. Later, when the application wants to parse the header, it has the string corresponding to the message and can hand it off to the parser, which can then fill in the appropriate fields corresponding to the header.
4. Subsequently, the application can access the fields just as an eager parser based application would do.

( Where am I missing the boat with this? )

An application has no idea whether an implementation is using lazy or eager parsing - it is simply passed a header object - and then if it is interested in a particular field it calls the appropriate get method (which would internally invoke the parser in a lazy parsing implementation). So the application is completely oblivious to whether or not this "optimisation" is used by the implementation.

If the field is optional and does not exist in the header a ParameterNotSetException will be thrown by the implementation. If the field is mandatory and does not exist, a JainSipParseException will be thrown (header is malformed). If any header field is malformed a JainSipParseException is thrown. If a JainSipParseException is thrown, this indicates that the application must use the header's getValue method to get a string representation of the header value and do what it can with that.

 

It appears that what is being attempted here (please correct me if I am wrong) is to use exceptions as a mechanism to catch un-initialized fields so the parser can be invoked in the exception handler perhaps. This leads to a lot of overhead in clunky code. I think it is a mistake to throw exceptions on every get to try to protect the application from inadvertently accessing fields that have not been initialized.  Why not just assume that the application must be smart enough to parse the header text before accessing fields and not try to provide a complex mechanism as above?


We are using ParameterNotSetException for the case of an optional header not existing, and a JainSipParseException for the case of a malformed header being received from the network.

If we assume the application is smart enough to do all header value parsing, we reduce a header to just being two strings - the type and value, which puts the burden of parsing on an application - this work can be done by the underlying implementation - doesn't it make more sense for an application to catch an exception than have to parse all header value strings (especially since this functionality already exists in the underlying stack)

 
 

Regards,

Ranga.

Chris Harris wrote:

Erik,

The implication of what you say is that all set methods in the header
interfaces which take String arguments must throw a checked
JainSipParseException. I think this is reasonable given that different
implementations will be more tolerant than others. However, in order to allow
lazy parsing by an implementation, all get methods in the header interfaces
(regardless of return type) must throw a checked parse exception. This is a
lot of checked exceptions - and will make life more awkward for the
application developer. It would certainly be much less effort to not allow
lazy parsing - there would be no need to throw a parse exception for all get
methods - greatly reducing the number of checked exceptions. Unfortunately it
has been said that JAIN SIP support for lazy parsing is a must. If it is then
I guess there is no other choice than to include the exceptions?

Regards,
Chris

Erik Nissen wrote:

> Chris Harris wrote:
>
> >
> > We need to decide whether this should be a checked or runtime exception.
>
> The rule of thumb is to use:
> * checked exceptions when the program should handle situations which
> can/will occur.
> * runtime exceptions when there are programming error (God forbid :-)
>
> So:
> Parse errors should throw checked exceptions.
> Becaurse parse errors are outside the control of the programmer
> and he/she should be forced to handle such conditions in the code.
>
> Null/wrong arguments should throw runtime exceptions.
>
> If it is possible, reduce the number of methods throwing (checked)
> exceptions
> to a minimum.
>
> Best regards,
> /Erik Nissen,
> Ericsson Utveckling AB

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

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
 
--------------D57D0BA92715AE252D49E90C-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 24 10:07:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02981 for ; Fri, 24 Nov 2000 10:07:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EC5B44399; Fri, 24 Nov 2000 09:07:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id CCBED44383 for ; Fri, 24 Nov 2000 09:06:00 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Nov 2000 07:06:02 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , "'Jonathan Rosenberg'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 24 Nov 2000 07:05:56 -0800 > > > So how does that help with the desired invariant property? I > > beleive using parameters would be better. > > I don't think it matters how the URI is formed, as typically > it's only going to make sense to the proxy that inserted it > (unless we come up with a BCP, or sommat). > > I think when I talk about this invariant, I don't necessarily > mean that the Request-URI along the entire route would be > routable by an arbitrary proxy; what I mean is that the > Request-URI would be routable at the salient proxy. > > I think what Jonathan didn't like -- and I wasn't happy about > it, either -- was that in the reverse direction, the Request-URI > could in no way ever have been useful in finding the calling > UA (save the case that the calling and called UA were the same, > perhaps). With the sorts of things being proposed now -- > having a different URI on request and response, or somehow > embedding the caller, say -- this is no longer the case. Sure, > it's likely that only the proxy that inserted the URI will > understand it, but that's in no way atypical, and I feel > still satisfies the invariant. I also like the idea. How about we express the invariant in the most simple way possible: the user portion of the Record-Route indicates the direction to the proxy (but it does not need to [necessarily] represent the original Request-URI/Contact - allowing the proxy to rely on such "slightly mangled original-uri" information, in my mind, is making things MORE brittle not less [and complicated] )? Anything else should be left up to the internal implementation of the proxy. eg including route state, original uri (if necessary), spiral tag (which should be recommended), etc. The ammount of information included in the Record-Route may be influenced by the ammount of information stored for the call and how routing is performed (eg the Request-URI may not actually be helpful in identifying the same routing destination for load-sharing or time-dependent routes). > > As for maddr handling: If the proxy is required to add the rr-uri > > parameter, then I think the proxy must also replace any maddr with > > a "rr-maddr" parameter so that the outgoning request-URI is > > faithfully recreated. > > I'm not sure why this is needed? Couldn't we just do something > like: Sorry, you're right I was getting confused - its not needed. > > Once again, all we can do is provide a recommendation for proxies > > not want to keep full state. So all we have to specify in > the spec is > > characteristics of what the base user@host is, right? > > I don't think we even need a user. > I don't think it would hurt having a user - it makes the invariant easier to express (as above). I don't know whether requiring a user part should be a SHOULD or MUST but I feel a SHOULD is more appropriate. [Boy, Jonathan's going to have a few emails waiting for him tomorrow.] Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 24 10:09:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03551 for ; Fri, 24 Nov 2000 10:09:36 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1063C443B9; Fri, 24 Nov 2000 09:09:10 -0500 (EST) 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 0DB02443BF for ; Fri, 24 Nov 2000 09:08:48 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eAOF8aB20512; Fri, 24 Nov 2000 16:08:36 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.34]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA14322; Fri, 24 Nov 2000 17:08:34 +0200 (EET) Message-ID: <3A1E8471.35C76E18@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip , mmusic Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] NEW I-D: fid SDP attribute Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 24 Nov 2000 17:08:33 +0200 Content-Transfer-Encoding: 7bit Hi, A new version of the SDP media alignment draft has been released: ftp://ftp.nordu.net/internet-drafts/draft-camarillo-sip-sdp-01.txt This draft defines an SDP attrubite to be used for SDP media alignment in SIP (MMUSIC & SIP WGs) 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 Fri Nov 24 10:15: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 KAA04746 for ; Fri, 24 Nov 2000 10:15:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7E361443D3; Fri, 24 Nov 2000 09:15:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id ABE2944383 for ; Fri, 24 Nov 2000 09:14:31 -0500 (EST) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Nov 2000 07:14:33 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 24 Nov 2000 07:14:22 -0800 > > > > > However, the parameters > > > > _are_ being treated as URL parameters in the Request-URI so the > > I think there's still a need to distinguish between Record-Route > parameters (that is, rr-params in section 6.34 of bis02) and the > parameters that a proxy adds to the SIP URL that it places in > a Record-Route value. Record-Route params might still prove to > be useful; they could be used so that a proxy can identify the > Record-Route entry that it added, for instance. > I agree. They should be distinguished and that's a very good suggestion for the using the former (Record-Route URL parameters?). What do we call the latter? Record-Route Request-URI parameters ? As for any complex escaping schemes, I think that we should be aiming to make Record-Route/Route as simple as possible - its complicated enough already. :) [Thank god we can now at least get rid of route mangling in the UA.] Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 24 10:28: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 KAA07581 for ; Fri, 24 Nov 2000 10:28:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2CEE1443DC; Fri, 24 Nov 2000 09:28:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8474E44398 for ; Fri, 24 Nov 2000 09:27:44 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA26927; Fri, 24 Nov 2000 10:27:31 -0500 (EST) Message-ID: <3A1E88E3.D1EBA4FE@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Lars Berggren , Jo Hornsby , Alan Johnston , Henry Chen , SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) References: <3A1B33DB.3D30D366@cs.columbia.edu> <20001121214009.A12322@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: Fri, 24 Nov 2000 10:27:31 -0500 Content-Transfer-Encoding: 7bit I'm not sure, but it seems that there's a simple fix: simply have the UA create *different* tags depending on whether this is for a From or To. However, the tag is constant across calls and requests. The general matching rule is - match incoming requests so that the To matches the locally generated tag and the From matches the tag generated by the other side Modifying the running example to use tag=5 for the To tag > I decide to call myself. I create a call-leg struct to represent it. > Let's call it "Line 1". I send out the initial INVITE: > > [From Line 1] > INVITE sip:me@proxy > Via: SIP/2.0/UDP my.ip > To: > From: ;tag=7 > Call-ID: 5 > > This eventually loops back to me. Now I see coming in: > > INVITE sip:me@proxy > Via: SIP/2.0/UDP some.ip > To: > From: ;tag=7 > Call-ID: 5 > > I check and see there is no To-tag, so this is a new incoming call. I > create a call struct to represent it, called "Line 2". Line 2 now > begins ringing. I respond with a 180 and the user switches lines and > answers the incoming call: > > [From Line 2] > SIP/2.0 200 OK > Via: SIP/2.0/UDP some.ip > To: ;tag=5 Modification here. > From: ;tag=7 > Call-ID: 5 > > When I receive this response, I find the related pending transaction. > Arguably, I could first find which call-leg it is destined to (and > immediately have a problem), but say that I do transaction mapping first > so we don't break yet. I match the OK and send an ACK: > > [From Line 1] > ACK sip:me@contactaddr > Via: SIP/2.0/UDP my.ip > To: ;tag=5 > From: ;tag=7 > Call-ID: 5 > > At which point the other pending transaction also correctly matches > this ACK to it. > > Now, on Line 2, I decide to hang up. I've had enough of talking to > myself. So, I send a BYE: > As usual, the callee simply flips To and From. > [From Line 2] > BYE sip:me@contact.addr > Via: SIP/2.0/UDP my.ip > To: ;tag=7 > From: ;tag=5 > Call-ID: 5 > > I now see this incoming BYE: > > BYE sip:me@contact.addr > Via: SIP/2.0/UDP some.ip > To: ;tag=7 > From: ;tag=5 > Call-ID: 5 > Using the rule above, it matches the call on line 1, since 7 is the locally-generated tag (stuck into From). > > Using unique tags per call avoids any confusion even in this case, and > also protects the UA against clients which always use the same tag and > happen to make two calls with the same Call-ID. Since both Line1 and Line2 have the same call-ID (one incoming and one outgoing), they would have the same locally generated tag according to your rule, so I don't see how this helps. Two calls with the same call-id can't happen, by definition. If they do, the implementation is broken (and would presumably generate the "wrong" tag, too, while it is at 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 Fri Nov 24 15:35: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 PAA18561 for ; Fri, 24 Nov 2000 15:35:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E146144367; Fri, 24 Nov 2000 14:35:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 1483944363 for ; Fri, 24 Nov 2000 14:34:22 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 24 Nov 2000 14:33:46 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Anders Kristensen , Jo Hornsby , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <20001124143346.A15961@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 24 Nov 2000 14:33:46 -0600 >> Like Robert I struggle with this RR URI which "identifies the >> [caller/callee] as a resource on this proxy". In the typical case >> only one of the two parties would be known in any meaningful way to >> the proxy. [...] > > My initial posting was not sufficiently detailed to explain this, so > let me clarify. > > The URL inserted into the request must be something that > (1) given the client follows the server location process in > draft-ietf-sip-srv-00, causes the URL to be resolved to an > address/port on the proxy, and > (2) is a URL that, if received by the proxy, the routing logic in the > proxy would cause the request to be forwarded to the Contact/From > address of the calling party. > > Similarly, the URL in the response must > be something that > (1) routes to the proxy, and > (2) is a URL whose routing logic in the proxy would cause the request > to be forwarded to the Contact/From address of the called party. I'm ok with (1) on both of these. (1) should be the same in both directions, and the proxy must know this address itself. If (1) isn't the same in each direction, the proxy can insert two record-routes. I don't understand the reasoning behind (2). If the message has a Route, you do NOT want the routing logic in the proxy to be applied, as this may have changed since the Route was set. The request MUST be routed according to the Route. Proxies which maintain state can of course put some magic parameter, but I don't see why this must be unique in each direction. However, if some proxy requires it, then it too can put in two Record-Routes, and then have enough smarts to remove both. I belive that all uses for Record-Route can be solved by using: With the exception of firewall proxies, where it is sufficient to use: If some middle-man snarfs the message, that's ok, because routing it to the request-URI will get it to the correct destination: the proxy, and that proxy can surely identify the message as being for it. From there, the proxy MUST use the Route to route it. Looking at your tuples: (A@originating.com;maddr=proxy, B@terminating.com;maddr=proxy) The only advantage I see is redundancy. If proxy is down, then maybe some clients might send the request to the rest of the address. However, this will avoid all of the other proxies in the Route. A better idea would be for a smart node to instead drop this entry from the Route and try the next URI. If this is purely information for the proxy to know, then fine they're free to do it, but I don't see any reason why this needs to be mentioned in the spec. Seems like a special (and complicated) case to me. How is more brittle? Trying to implement the tuple scheme: finding an algorithm to copy the request-URI and add in an maddr of the proxy, finding your record-route in the response and mangling it, seems awfully brittle in itself. I have been told that using the maddr technique helps protect against UAs which don't insert a Contact. However, I can't come up with a scenario, and now Contact is mandatory for INVITEs and 200-class responses. >> Additionally, if the proxy is keeping full call state, eg based on >> unique Call-Id. Is it REQUIRED to mess with the Record-Route in the >> response. Otherwise, adding a simple > > I think yes, since otherwise we won't achieve this property of the > request URI referring to a resource that would cause the request to be > routed to the appropriate party. The appropriate party is the proxy. After that, the appropriate party is spelled out clearly by the Route. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Nov 24 16:42: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 QAA03437 for ; Fri, 24 Nov 2000 16:42:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 404DA4436C; Fri, 24 Nov 2000 15:42:20 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C3AE444363 for ; Fri, 24 Nov 2000 15:41:51 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA12709; Fri, 24 Nov 2000 16:41:43 -0500 (EST) Message-ID: <3A1EE097.7ACDFF65@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs , sip@lists.bell-labs.com References: <20001030224808.B31229@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: My comments on bis-02 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 24 Nov 2000 16:41:43 -0500 Content-Transfer-Encoding: 7bit An updated version of -02 (to be submitted) is at the www.cs.columbia.edu/sip location. I would appreciate if you could check which of your remarks still apply. In terms of "fluff", the only way to forward progress is if folks specifically identify redundant wording. I'm all for shortening the spec, but not if it means that you have to read FAQs, papers and mailing lists to start working on the implementation. Thanks for the comments. Billy Biggs wrote: > > These are some of my (late) issues with bis-02. BTW, It would help > for commenting on the draft if there was a text file version. > > Comments which may require discussion > ------------------------------------- > > 1. In 4.2.1 there is discussion about how to handle INVITEs which cross > on the wire. Are you worried about when two endpoints change their > contact address at the same time? If you're just worried about the > session changing, it seems that it would be more > interoperability-friendly if implementations just re-re-INVITE'd when > they believe requests may have crossed, and use some internal random > timer. This has been discussed a few times on the list, but may need to be rolled up again. > > 2. In 4.2.5, it is noted that CANCEL requests cannot have Route headers. > Why not? Are you assuming that CANCEL is only useful for an initial > request? This breaks since we need to be able to CANCEL a pending > REFER or other extension method which doesn't complete quickly, for > example. > Removed. > 3. Sections 6.25 and 10.1.1 (maybe others), as I mentioned in another > post to the list, imply that clients should choose a single local tag > and preserve this across calls. This is a bad idea in cases when UAs > call themselves, may lead to UAs choosing the same tag value in some > cases, and also poses a security risk. > > I strongly recommend that the recommendation change to be that tags > should always be unique. Apologies to those implementations that > want to try and preserve calls over reboots. I don't see much point > to section 11.5 either. Using the same tag doesn't solve all the > problems, so why bother trying? It just makes things confusing and > prone to failure. Obviously, separate discussion. Clarified as indicated in my email for now. > > 4. Regarding Authentication in 13.2, is it the responsibility of the > UAC to not use short form headers after the Authorization, or is it > the responsibility of the proxy to switch them when transforming the > message into canonical form? Text says "Clients wishing to authenticate requests ... no short form header fields". I'm not sure what's ambiguous here. > > I ask because there are extensions to SIP which propose new short > forms for headers that proxies will not know about. An example of > this is the REFER draft. Should the UAC not use these short forms, > or should extensions not propose them? > > 5. Due to the proliferation of the Also header in BYE requests, I would > suggest that it be added to the bis draft, with its meaning > restricted to use with the BYE method. Tentatively added. > > 6. Mid-Call redirects. The wording for the 305 response code seems to > indicate that it can be sent mid-call. This breaks if you have a > Route. I guess the only reasonable thing to do is say that if you > get redirected mid-call you should drop your route? Or even better, > tell UAs that they cannot send a redirect response to a request with > a To tag? Regardless, the bis draft should mention this case. Any mid-call INVITE can return a 3xx. I can't see why 305 is special in this regard. This does not necessarily mean that the route is bad, as the Contact will just be added to the bottom. Yes, future requests may travel strange hairpin paths, but, with care, a proxy can recuse itself out of route. > > 7. See my last post regarding the scope of the Call-ID. > > Comments which are just bugs > ---------------------------- > > 8. It would be nice in section 16 if all of the examples included from > tags. As well, Figures 1 and 2 don't have tags. Figure fixed; tags added. > > 9. Section 4.2.6 explicitly mentions that REGISTER messages can be > redirected. This seems redundant. I also believe that there are > other areas of the spec where it is quite verbose and redundant. > While this is to the benefit of new readers in some cases, the draft > is also now quite large. Can we maybe try and strip some of the > fluff out? Section removed. Other suggestions welcome. > > 10. Section 1.4.6 says Call-ID when it means "within the same call leg". > > 11. In section 7.4.1, as was noted somewhere, "Missing Content-Length > header" is a bad example unless it is now mandatory. Changed to Missing Call-ID header > > 12. Section 1.4.2 implies that clients do not need to support UDP. I > think this is a bug. > Please see if this is still a problem. > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com -- 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 Sun Nov 26 11: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 LAA15325 for ; Sun, 26 Nov 2000 11:25:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A9CAC44337; Sun, 26 Nov 2000 10:25:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 46ACC44336 for ; Sun, 26 Nov 2000 10:24:13 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eAQGNnY01284; Sun, 26 Nov 2000 10:23:49 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id KAA08169; Sun, 26 Nov 2000 10:23:49 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA14266; Sun, 26 Nov 2000 10:23:48 -0600 (CST) Message-ID: <3A20D66E.EAE34429@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Jo Hornsby'" , hgs@cs.columbia.edu, sip@lists.bell-labs.com, Billy_Biggs@3com.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 26 Nov 2000 10:22:54 +0100 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Before we begin writing new text, lets look at the sub-problems and build up > a solution. I have another possibility that may be the best of all worlds. > I'll start with Roberts list: > > 1. non SIP URLs in request URI > > We can either define record-route parameters, or else make sure that the URL > put into the record route is a sip url. I originally propose RR parameters, > but I think insisting on a SIP URL is backwards compatible and more > reasonable. That seems to be consensus. Please do not make this mistake. If we don't require a SIP URL in the Request-URI, the From, the To, or even the Contact, then why mandate it in the Record-Route:? -- 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 Nov 26 11:32:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17464 for ; Sun, 26 Nov 2000 11:32:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D38EC4434A; Sun, 26 Nov 2000 10:32:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 1FAC344349 for ; Sun, 26 Nov 2000 10:31:25 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eAQGU8Y01766; Sun, 26 Nov 2000 10:30:08 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id KAA08426; Sun, 26 Nov 2000 10:30:08 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA14363; Sun, 26 Nov 2000 10:30:08 -0600 (CST) Message-ID: <3A20D7E9.9E2FDE77@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: kajun Robert Cc: sip@lists.bell-labs.com Subject: Re: [SIP] the parser References: <200011221826254.SM00159@AspEmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 26 Nov 2000 10:29:14 +0100 Content-Transfer-Encoding: 7bit This is purely an implementation choice (obviously). There are so many variables that enter into this choice that it is impossible to state a definitive answer. I fall in the camp of doing as little as possible in the parser, but there are good reasons for doing strict syntax checking as you mention for some applications. The "@" character should not be escaped. Escaping this character changes the semantics of the URL. My two cents -- Sean Olson kajun Robert wrote: > hi, > I don't know what the parser should do and it seems that the parser has muddled me. Can you help me? I think it should check the message byte-by-byte to ensure that every character has fallen into a specific field, such as unreserved filed, DIGIT filed etc. Also the parser can find the syntax error besides the characters falling into some fields. For example, the parser should find the errors such as "%4q", 101.3332.3.5 (the Ipv4address) and so on in the Request-URL, although the characters are allowed to appear in the message. > Is that true? Also I am not sure the @ character can be escaped. If it can be escaped, the parser would not have mechanism to distinguish the one that the Spec requests with the one that the user's own escaped character? > Thanks. > Robert Kajun > > ________________________________________________________________________ > Get Your Free International E-mail from Langoo.com at http://www.langoo.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 26 11: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 LAA18051 for ; Sun, 26 Nov 2000 11:33:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44CE844354; Sun, 26 Nov 2000 10:32:23 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 2BB2244349 for ; Sun, 26 Nov 2000 10:31:59 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eAQGVlY01970; Sun, 26 Nov 2000 10:31:48 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eAQGTJT15639; Sun, 26 Nov 2000 10:29:19 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA14378; Sun, 26 Nov 2000 10:31:47 -0600 (CST) Message-ID: <3A20D84C.B2B6675@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Arun Kumar Chippada Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Help with sip References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 26 Nov 2000 10:30:53 +0100 Content-Transfer-Encoding: 7bit Yes and Yes. You can choose different ports for each server or you can do some clever magic to run both on the same port. I leave it as an excercise for the reader to figure that one out. -- Sean Olson Arun Kumar Chippada wrote: > Dear All, > > We want to know whether it is possible to run a SIP Proxy Server and a > SIP User Agent on the same machine. Has anyone ever tried to do this? > > Arun. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 26 19:41: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 TAA09645 for ; Sun, 26 Nov 2000 19:41:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D039244345; Sun, 26 Nov 2000 18:41:09 -0500 (EST) 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 5095344336 for ; Fri, 24 Nov 2000 00:37:53 -0500 (EST) 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 MAA10064 for ; Fri, 24 Nov 2000 12:16:58 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA4D1D; Fri, 24 Nov 2000 11:58:23 +0530 Message-ID: <00c701c055e1$db529980$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Jonathan Rosenberg" Cc: "Robert Sparks" , References: Subject: Re: [SIP] Possible REFER problem? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 24 Nov 2000 12:13:29 +0530 Content-Transfer-Encoding: 7bit My two cents of thoughts on this one... I don't know how feasible my suggestion below is. The crux of this problem in my opinion here arises out of the fact that the Transferor is first initiating an INVITE to check the availability of the transfer target and depending upon the type of transfer, the TT (or the transferree) initiates an INVITE to the transferree(or TT) based either upon the request URL / contact URL received. This problem could be solved if the transferee invoked the INVITE in all cases. Venkatesh ----- Original Message ----- From: "Jonathan Rosenberg" To: "'Billy Biggs'" ; "Robert Sparks" Cc: Sent: Friday, November 24, 2000 9:06 AM Subject: RE: [SIP] Possible REFER problem? > Sorry for the delay in picking this thread up... I'm trying to finish a rev > on Caller Prefs, and there are some issues here. > > First off, Eric raised a problem with my proposed solution. I'm replicating > it here since its been a while: > > > If you remember, the problem was when doing call transfer > > with consultation > > with the REFER request, how can we make sure that the INVITE > > request (from > > the Transferee to the Transfer Target) is going to reach the > > exact same > > User-Agent as the one that was consulted by the Transferor. > > > > The solution was to use the header "Accept-Contact" and > > specify the contact > > of the transfer target. > > > > I was taking a look at the caller preferences extension, thinking that > > "Accept-Contact" had solved our problem, but I think it does > > not solves the > > problem. > > > > Suppose we have the following participants: > > > > Transferor (Tror) > > - Sip address: sip:tror@acme.com > > - Current location: sip:tror@office1.acme.com > > > > Transferee (Tree) > > - Sip address: sip:tree@acme.com > > - Current location: sip:tree@office1.acme.com > > > > Transfer-Target (TT) > > - Sip address: sip:tt@acme.com > > - Current location: sip:tt@office4.mediatrix.com > > > > > > Tror and Tree have established calls. Tror contacts TT and > > ask if he wishes > > to accept the call, which he does. Tror sends the following > > REFER to Tree: > > > > REFER sip:tree@office1.acme.com SIP/2.0 > > From: sip:tror@acme.com > > To: sip:tree@acme.com > > Refer-To: sip:tt@acme.com?Accept-Contact=sip:tt@office4.mediatrix.com > > ... > > > > Which spawns the INVITE from Tree to a proxy server somewhere in ACME. > > > > INVITE sip:tt@acme.com SIP/2.0 > > From: sip:tree@acme.com > > To: sip:tt@acme.com > > Accept-Contact=sip:tt@office4.mediatrix.com > > Referred-By: ... > > ... > > > > > > The proxy receives this request and checks with the location > > server to find > > where can tt@acme.com be found. The list of contact returned > > could look > > like the following: > > > > Contact: sip:tt@office1.acme.com > > Contact: sip:tt@mediatrix.com > > Contact: sip:assistant@office1.acme.com > > > > Now the proxy has these 3 contacts that do not match the > > Accept-Contact URL, > > although the proxy at mediatrix.com would translate > > tt@mediatrix.com to > > tt@office4.mediatrix.com. Now the proxy does not really know > > which contact > > is prefeered, and can try any of the three contacts, and > > someone can happily > > answer at those addresses. > > > > How can we avoid this? > > > > First, I think that the Proxy should send the Accept-Contact in its > > downstream requests, in order to have the downstream proxies > > be able to use > > the same mechanism. But in truth, the proxy does not know if > > the downstream > > request is going to be sent to a proxy or to a UA, so it is > > possible for a > > UA to receive such a request. Would it be a good idea to > > have the UA take a > > look at the Accept-Contact header to know if the request is > > really for him? > > I think that the current caller preferences draft states that > > a UA should > > ignore these header if it receives it. > > Eric is correct that even if none of the registered contacts matches those > in the Accept-Contact header, a proxy will forward the request, with > Accept-Contact intact. As a result, the request may ultimately arrive at > several UAs that don't match. Another related problem is that Accept-Contact > is not specified as a filter-all-but rule (partly for the reasons Eric > observes; a request would never get past the first proxy since the Contact > might be known only at a later proxy). The caller preferences specification > has a process for combining the q values. At best, it would effect ordering > of a sequential search. > > What we need here is a mechanism that says, "I only want to talk to you if > you are one of these Contacts". This rule can ONLY be enforced in the UAs. > This capability does not exist in the current caller preferences draft. > However, I think it will prove useful here (actually, it really is needed > for call transfer, more on that below), and other places too. So, I will add > an Accept-Only-Contact header to caller preferences, with this header only > being used by a UA. > > Now, on to some other issues. Consider the scenario of A talking to B. A > calls C, and then A wishes to transfer B to C, making sure that B gets the > same instance of C that A was talking to. Adam asked, why not have A refer B > to the Contact obtained from C: > > > At the risk of sounding daft, I don't see why using the "Contact:" > > header as the new "INVITE" URI is considered Evil in this case. > > > > When explaining the difference between, say, the "From:" (or "To:") > > field and the "Contact:" field, I generally think of "From:"/"To:" as > > being the persistent URI for contacting the appropriate resource in > > an abstract sense (by resource, I mean "Adam Roach" or > > "helpdesk staffer" > > or "sales representative"), while the "Contact:" URI > > indicates "where to > > get to me (as a particular instance of that resource) on this > > particular > > device at this particular moment." > > The answer is that URIs most definitely have a context; a place from which > they can be usefully used. In a perfect world with no NATs, firewalls, or > devices that want to know whats going on within the network, it would work > dandy. But thats not reality. The classic example is an ACD application, > where help@helpdesk.com can be routed to a variety of agents > (agent32@host32.helpdesk.com). Sophisticated software tracks the call status > of the various agents, how much volume they get, etc. Incoming calls MUST > come in through this helpdesk proxy to work. The proxy always record routes. > In fact, to enforce this, the proxy has access to a hosts file with the > host32.helpdesk.com address mapped to an IP address. Outside of this proxy, > that hostname is unroutable. So, if A called B, and then A called C, and C > was one of these operators, the URI returned by C > (agent32@host32.helpdesk.com) will definitely not be useful for B to use > directly. > > Another issue was raised about the possibility of per-call Contacts > generated dynamically by a UA. Yikes. I don't know any UA that does this. > Unfortunately, if a UA provides no consistent form of identification to the > network or other users, it can't expect to be consistently transferred to in > this case. So, I think we can punt this case and declare it as "don't do > this". > > Robert had proposed a hybrid approach: > > Given all that, and the likelyhood that for many (if not > > most) instances, the contact provided in the Contact URL > > _is_ routable, what problems exist with taking the following > > approach? > > > > 1) REFER B directly to the contact that C provided to A. > > 2) If it fails, REFER B to C's well known URL with an Accept-Contact > > header containing the contact that C provided to A. > > > > Hmm. Turns out you can construct cases where neither (1) nor (2) will work. > > What if, when A called C, it wasn't really C that was called, but some > time-of-day routed 800 number that got forwarded to C. Now, while A talks to > C, the logic for the forwarding changes. Now, when A sends a REFER to B, the > URI in the Refer-To is that 800 number. It never even comes close to being > sent to a single UA that matches the Accept-Contact header. In this > scenario, sending directly to the Contact won't work either, since the > operator is not directly callable. Don't you love feature interaction > problems ;) ? > > So, basically, referring to exactly the same person I'm talking to is hard > because (1) their unique address may not be directly routable, and (2) the > logic used to get to that person from a directly routable address may > change. If you ignore (1), you come up with the solution to (2) of sending > to the Contact. If you ignore (2), you come up with the Accept-Only-Contact > solution to deal with (1). If you want to deal with both (1) and (2), its > really rough. I thought about having A also include Route headers as header > params to the URI in the Refer-To, but this doesn't work either. A route > header set usable from A may not be usable from B, for many reasons, not the > least of which is problem (1) once more. > > Perhaps these cases are so extreme its not worth worrying about. I wouldn't > be surprised if they don't work in the PSTN either. > > So, despite its complexity, I feel compelled to recommend that Robert's > hybrid approach be described in the REFER specification as the preferred way > to do transfer out of consultation, along with a nice long explanation of > why it needs to be so. I'm not sure about the order though. I suspect that > (2) will work in far more cases than (1) will. I welcome better ideas if > anyone has any... > > > 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 26 19:42: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 TAA10031 for ; Sun, 26 Nov 2000 19:42:48 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C43F44363; Sun, 26 Nov 2000 18:41:23 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from i3exchange.inin.com (mail.inter-intelli.com [204.180.46.4]) by lists.bell-labs.com (Postfix) with ESMTP id 0997244336 for ; Fri, 24 Nov 2000 07:14:12 -0500 (EST) Received: by i3exchange.inin.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Nov 2000 08:17:03 -0500 Message-ID: From: "Snyder, Duke" To: sip@lists.bell-labs.com Subject: RE: [SIP] Multiple headers of a given type. 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, 24 Nov 2000 08:17:01 -0500 1. What is the preferred method (single header with multiple elements or multiple headers with a single element). 2. I assume you can get a mixture (multiple via headers, some with multiple elements). 3. Can a server, when resending, change the format (change the list format to the multiple header format). The server I'm writing decodes them but encodes them the same way, regardless of how they were received. I don't keep track of how they were initially received. 4. Why support both methods in the first place. Backward compatibility? -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, November 23, 2000 9:30 PM To: 'mranga@nist.gov'; sip@lists.bell-labs.com Subject: RE: [SIP] Multiple headers of a given type. Since a comma separated list of values (indicated in BNF with #) is identical to multiple headers of the same name, any header whose BNF starts with # can appear more than once. -Jonathan R. -----Original Message----- >From: M. Ranganathan [mailto:mranga@nist.gov] >Sent: Thursday, November 23, 2000 9:01 PM >To: sip@lists.bell-labs.com >Subject: [SIP] Multiple headers of a given type. > > >Hello! >This is a rather simple question. Of all the SIP headers in the bis document, which can >appear multiple times in a Request / Response ? (For example, VIA can appear multiple >times, ACCEPT can appear multiple times etc. but FROM can appear only once and TO can >appear only once. ) If there is a table in the document giving this information I have >missed, please let me know (and apologies for redundant mail). >Thanks. >Regards >Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --- 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 Sun Nov 26 22:15: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 WAA18677 for ; Sun, 26 Nov 2000 22:15:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A8F7544349; Sun, 26 Nov 2000 21:15:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1494A44336 for ; Sun, 26 Nov 2000 21:14:39 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA01239; Sun, 26 Nov 2000 22:16:57 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Nov 2000 22:12:38 -0500 Message-ID: From: Jonathan Rosenberg To: "'discussion@sipforum.org'" Cc: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: [SIPFORUM] Sending binary data instead of text Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 26 Nov 2000 22:12:33 -0500 First off, questions on sip itself belong on the sip list (sip@lists.bell-labs.com), not the sip forum. Answering your question: -----Original Message----- >From: Naresh Kumar Agarwal [mailto:naresh@mediaring.com.sg] >Sent: Saturday, November 25, 2000 9:37 PM >To: discussion@sipforum.org >Subject: [SIPFORUM] Sending binary data instead of text > > >Hi, > >Is it possible to send binary data in SIP at times apart from text. Yes, the body of SIP is 8 bit clean and can carry pure binary data. > >If yes, can we send the data in the binary form itself or does it needs to be converted to >text first? Pure binary. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Nov 26 22:21: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 WAA20472 for ; Sun, 26 Nov 2000 22:21:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09BF64437F; Sun, 26 Nov 2000 21:21:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 712C64437D for ; Sun, 26 Nov 2000 21:20:53 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA01268; Sun, 26 Nov 2000 22:23:07 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Nov 2000 22:18:48 -0500 Message-ID: From: Jonathan Rosenberg To: "'discussion@sipforum.org'" Cc: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: [SIPFORUM] Queries Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 26 Nov 2000 22:18:46 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA20472 Once again, please direct all sip technology questions to the sip list, sip@lists.bell-labs.com. -----Original Message----- >From: Naresh Kumar Agarwal [mailto:naresh@mediaring.com.sg] >Sent: Saturday, November 25, 2000 9:42 PM >To: discussion@sipforum.org >Subject: Re: [SIPFORUM] Queries > > >Hi Jorgen, > >1. Hopefully, the following diagram should make things slightly clearer. > > >SIP_CLIENT PROXY_LOCATOR SIP_PROXY >| | >| >| 1)invite(client identifier, data1) | | >|------------------------------------------------->| >| >| 2) 302 OK (SIP_PROXY_IP,data2) | | >|<-------------------------------------------------| >| >| | >| >| 3)invite(client identifier, data2) | >|-------------------------------------------------------------------------- ---------------->--->| > > >In this flow, data2 is something which is sent by the Proxy Locator upon receiving the >invite from the SIP Client. The Locator passes this data to the SIP Client >but doesn't expect it to interpret it (it is intended for the destination SIP Proxy). But >at the same time, the SIP Client needs to interpret the IP address of the SIP >Proxy sent in the 302 OK. Your question came across as confusing, since there is no such thing as "proxy locator" in the sip specifications or related documentations. This is a redirect server. The answer to your question, however, is yes. There is a way for the redirect server to pass information to the client, which the client will pass to the proxy. The client won't do anything with the data. It will be placed in the request sent to the proxy. Of course, if this is non-standard data, it will be meaningless to the proxy unless there is some kind of specialized logic in the redirect server and proxy. Dangerous thing to do, in general. If you need something from SIP thats not already there, you should raise that issue instead of attempting non-standard extensions, which is what this is. ANyway, the way to send data is to encapsulate it as a header in the redirected URL: 302 Try Here SIP/2.0 Contact: sip:user@host;maddr=proxy.me.com?newheader=foo The client then sends an INVITE to proxy.me.com: INVITE sip:user@host SIP/2.0 newheader: foo From: sip:me@caller ..... -Jonathan R. ----- Original Message ----- From: Jörgen Björkner To: discussion@sipforum.org Sent: Sunday, November 26, 2000 1:37 AM Subject: RE: [SIPFORUM] Queries Hi, 1) I am not sure that I really understand what you ask for. Could you clarify with a small message flow diagram, since I am a but confused from what you mean with client passing on data. 2) I remember some discussion on the SIP list of using SIP for key exchange. I think that the result was that there is a lot of things to think of when designing a key interchange protocol, and therefore is it better to use one of the already developed key exchange protocols for this purpose instead. Although SIP provides digest authentication, but this requires a shared secret between the parties. (Is this the right answer, should I add it to the SIP FAQ?) 3) Yes, you can use PGP, for key distribution see answer 2) /Jörgen -----Original Message----- From: owner-discussion@listserver.wineasy.se [mailto:owner-discussion@listserver.wineasy.se]On Behalf Of Naresh Kumar Agarwal Sent: den 24 november 2000 17:49 To: discussion@sipforum.org Subject: [SIPFORUM] Queries Hi, Would be grateful if any of you could help answer the following queries I have: 1) During communication between a SIP client and a proxy locator (which is used to find the location of a SIP proxy), is it possible for the proxy locator to send some data (which is like a black box to the SIP client and it does not need to interpret: something which it can simply pass on to the SIP proxy later). This data (black box) will be sent along with some other data which the client might need to interpret. Thus, what I want to find out is whether there is a SIP mechanism (some tag, or something else) whereby a client can differentiate between data that it needs to interpret and that it needs to simply pass on. 2) How do we do challenge in SIP? Can we use the "challenge" mechanism for key-exchange (for security reasons) in SIP? If so, how? 3) I believe SIP supports PGP (Pretty Good Privacy). In this case, how do they actually get the key of the called-party? Regards, Naresh Agarwal. --- 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 Nov 27 00:35: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 AAA19431 for ; Mon, 27 Nov 2000 00:35:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 545ED44342; Sun, 26 Nov 2000 23:35:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 126F444336 for ; Sun, 26 Nov 2000 23:34:43 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sun, 26 Nov 2000 23:34:34 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: SIPForum Discussion List , SIP List Subject: Re: [SIP] RE: [SIPFORUM] Queries Message-ID: <20001126233433.A24967@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Sun, Nov 26, 2000 at 10:18:46PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 26 Nov 2000 23:34:33 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > Anyway, the way to send data is to encapsulate it as a header in the > redirected URL: > > 302 Try Here SIP/2.0 > Contact: sip:user@host;maddr=proxy.me.com?newheader=foo > > The client then sends an INVITE to proxy.me.com: > > INVITE sip:user@host SIP/2.0 > newheader: foo > From: sip:me@caller > ..... Picky point, but the start line should be: INVITE sip:user@host;maddr=proxy.me.com SIP/2.0 Please be friendly to transparent proxies. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 00:41: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 AAA21233 for ; Mon, 27 Nov 2000 00:41:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5693F44389; Sun, 26 Nov 2000 23:41:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C3B2044387 for ; Sun, 26 Nov 2000 23:40:09 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01673; Mon, 27 Nov 2000 00:42:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 00:38:09 -0500 Message-ID: From: Jonathan Rosenberg To: "'Snyder, Duke'" , sip@lists.bell-labs.com Subject: RE: [SIP] Multiple headers of a given type. 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, 27 Nov 2000 00:38:07 -0500 > -----Original Message----- > From: Snyder, Duke [mailto:Duke.Snyder@inin.com] > Sent: Friday, November 24, 2000 8:17 AM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] Multiple headers of a given type. > > > 1. What is the preferred method (single header with multiple > elements or > multiple headers with a single element). There is none that is preferred. SIP does define a canonical form that is used for authentication. My personal recommendation is to always generate canonical form. Its in section 13.2 of rfc2543. > 2. I assume you can get a mixture (multiple via headers, > some with multiple > elements). Yes. > 3. Can a server, when resending, change the format (change > the list format > to the multiple header format). The server I'm writing > decodes them but > encodes them the same way, regardless of how they were > received. I don't > keep track of how they were initially received. Yes, it can change the format. However, if the request is authenticated, you'd better spit it out in canonical form (and that had better be the form it was received in). > 4. Why support both methods in the first place. Backward > compatibility? We lifted much of SIPs operation from HTTP, which does this as well. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 01:06:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25247 for ; Mon, 27 Nov 2000 01:06:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57FB444340; Mon, 27 Nov 2000 00:06:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id F26C744336 for ; Mon, 27 Nov 2000 00:05:17 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 27 Nov 2000 00:05:08 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: SIP List Subject: Re: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examples-00.txt) Message-ID: <20001127000507.B24967@div8.net> References: <3A1B33DB.3D30D366@cs.columbia.edu> <20001121214009.A12322@div8.net> <3A1E88E3.D1EBA4FE@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A1E88E3.D1EBA4FE@cs.columbia.edu>; from hgs@cs.columbia.edu on Fri, Nov 24, 2000 at 10:27:31AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 27 Nov 2000 00:05:08 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > I'm not sure, but it seems that there's a simple fix: simply have the > UA create *different* tags depending on whether this is for a From or > To. However, the tag is constant across calls and requests. Even safer to use "predictable-random", however: Choosing predictable tags does not make a UA crash-proof. The SIP spec should not recommend any behavior on generating tags. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 01: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 SMTP id BAA28182 for ; Mon, 27 Nov 2000 01:16:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F13AA44387; Mon, 27 Nov 2000 00:16:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 4EADC44336 for ; Mon, 27 Nov 2000 00:15:32 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 27 Nov 2000 00:15:09 -0600 (CST) From: Billy Biggs To: Sean Olson Cc: Jonathan Rosenberg , "'Jo Hornsby'" , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <20001127001509.C24967@div8.net> References: <3A20D66E.EAE34429@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A20D66E.EAE34429@ericsson.com>; from sean.olson@ericsson.com on Sun, Nov 26, 2000 at 10:22:54AM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 27 Nov 2000 00:15:09 -0600 Sean Olson (sean.olson@ericsson.com): > > 1. non SIP URLs in request URI > > > > We can either define record-route parameters, or else make sure that > > the URL put into the record route is a sip url. I originally propose > > RR parameters, but I think insisting on a SIP URL is backwards > > compatible and more reasonable. That seems to be consensus. > > Please do not make this mistake. If we don't require a SIP URL in the > Request-URI, the From, the To, or even the Contact, then why mandate > it in the Record-Route:? Do you want Record-Route and Contact header parameters indicating the IP address and port to send the request? I don't mind non-SIP URLs, but I do mind new parameters: they just provide a false sense of security that things will magically work. If you put a non-SIP URL in the Contact or Record-Route or Request-URI, you had better know for sure that whomever is going to process the message knows how to forward it on its own. Non-SIP URLs in the To/From don't matter because Contact is now mandatory pretty much everywhere. You don't need to look at the From to route messages. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 01:31:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01859 for ; Mon, 27 Nov 2000 01:31:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 444BE4433B; Mon, 27 Nov 2000 00:31:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 80E8144336 for ; Mon, 27 Nov 2000 00:30:01 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 27 Nov 2000 00:29:52 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: SIP List Subject: Re: [SIP] Re: My comments on bis-02 Message-ID: <20001127002952.D24967@div8.net> References: <20001030224808.B31229@div8.net> <3A1EE097.7ACDFF65@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A1EE097.7ACDFF65@cs.columbia.edu>; from hgs@cs.columbia.edu on Fri, Nov 24, 2000 at 04:41:43PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 27 Nov 2000 00:29:52 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > An updated version of -02 (to be submitted) is at the > www.cs.columbia.edu/sip location. I would appreciate if you could > check which of your remarks still apply. Many thanks. I will give more detailed comments soon. > > 2. In 4.2.5, it is noted that CANCEL requests cannot have Route > > headers. Why not? Are you assuming that CANCEL is only useful > > for an initial request? This breaks since we need to be able to > > CANCEL a pending REFER or other extension method which doesn't > > complete quickly, for example. > > Removed. I think I was wrong on this one. CANCEL is of hop-by-hop significance within a transaction and doesn't use the Route. Stateful proxies instead remember and the UA sends the CANCEL just to the first entry in the Route. > > 6. Mid-Call redirects. The wording for the 305 response code seems > > to indicate that it can be sent mid-call. This breaks if you > > have a Route. I guess the only reasonable thing to do is say > > that if you get redirected mid-call you should drop your route? > > Or even better, tell UAs that they cannot send a redirect > > response to a request with a To tag? Regardless, the bis draft > > should mention this case. > > Any mid-call INVITE can return a 3xx. I can't see why 305 is special > in this regard. This does not necessarily mean that the route is bad, > as the Contact will just be added to the bottom. Yes, future requests > may travel strange hairpin paths, but, with care, a proxy can recuse > itself out of route. I don't see how proxies can recuse themselves out of the Route. It has come up before on this list: once the Route is setup it may not be modified, only the Contact at the end may change. Thank you for clarifying the meaning of a mid-call redirect. Time to fix code. > > 12. Section 1.4.2 implies that clients do not need to support UDP. > > I think this is a bug. > > Please see if this is still a problem. The text currently is: "If no protocol is specified, the client tries UDP (if UDP is supported). If the attempt fails, or the client doesn't support UDP but supports other protocols, it tries those protocols in some unspecified order." This implies that clients do not need to support UDP. I thought UDP was a requirement, but it looks like it's only a SHOULD for clients. MUST is only used in the section on a minimal implementation. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 10:07:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07433 for ; Mon, 27 Nov 2000 10:07:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2C644433E; Mon, 27 Nov 2000 09:07:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B9FB744336 for ; Mon, 27 Nov 2000 09:06:26 -0500 (EST) Received: from dynamicsoft.com ([212.120.151.233]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA03371; Mon, 27 Nov 2000 10:08:35 -0500 (EST) Message-ID: <3A22781D.901412E0@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: jainsip@sun.com, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A16922C.EFDE9019@ericsson.com> <3A1A5BAC.A0975580@dynamicsoft.com> <3A1DC4BD.533272E6@nist.gov> <3A1E82FB.DA1FC1AC@dynamicsoft.com> <3A1E8DEE.EA2DACA0@nist.gov> Content-Type: multipart/alternative; boundary="------------411948D645674E2B35A78E41" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 15:05:02 +0000 --------------411948D645674E2B35A78E41 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ranga, My comments are in red... Chris "M. Ranganathan" wrote: > Chris, > > Thanks for the prompt response. Hope you had a great Thanksgiving. I wish there was such a thing as Thanksgiving in Ireland :( > > > My followup is below. ( in blue) > > Regards > > Ranga. > > Chris Harris wrote: > >> Ranga, >> >> See comments below. >> >> Regards, >> Chris >> >> "M. Ranganathan" wrote: >> >> > >> > Chris, Erik, >> > >> > While we are on the subject of Exceptions, why do null arguments >> > throw runtime exceptions when you do a get on them? For example, in >> > the Accept interface, getContentSubtype throws a >> > IllegalArgumentException if is null. IMHO, I think it is valid to >> > have a null subtype so why not just return null rather than throw >> > exception here? >> >> By a "doing a get on a null argument" here I assume you mean >> attempting to get a non-existent optional field? If you do this a >> checked ParameterNotSetException is thrown, not a runtime exception. > > > Yes. Thats what I had meant. The word "argument" should have been > "field". Why do you need a ParameterNotSet exception in this case? > Are you trying to handle the case of basic types like integers, floats > and so on ? For objects, null is synonymous with not set isnt it? We discussed this matter in depth at the last JAIN SIP meeting in October, and we came to the conclusion that getting and setting null values is not a good idea for several reasons e.g. it is easier to debug a ParameterNotSetException than searching for the source of a later NullPointerException, and it forces the application to allow for the fact that there is a reasonable chance that a particular field does not exist. [Of course, if we did allow the use of null, we could cut down on the number of methods and drop the ParameterNotSetException - but is it really worth sacrificing clarity and robustness for the sake of cutting down on API size?] > > >> >> >> There are two approaches to handling optional header parts. One >> approach is to allow the passing and returning of null objects from >> get and set methods (implicit "remove" and "has"), and the other is >> to explicitly add has and remove methods (and exceptions on the set >> and get methods). As for mandatory header parts - I think passing >> null to a set method should definitely throw an >> IllegalArgumentException. > > I have the following questions about setXXX methods: > > 1. Why do you restrict throwing IllegalArgumentException to only null > arguments in some of the headers? Why are you not checking for proper > formatting of the passed arguments (by giving it to the parser for > example and running the appropriate parser rule). In general, an IllegalArgumentException is thrown if an argument to a set method fails basic validation (i.e. no implementation-specific parsing is used). Note that an application can ensure that this exception is not thrown by following the rules defined in the API . So if an argument is a String, I throw an IllegalArgumentException if the argument is null or zero-length. Of course this is not sufficient validation and the string must be parsed to check for whitespaces, newlines etc, and different implementations will be more tolerant than others. This is why there is a checked JainSipParseException - an application cannot tell in advance if a particular implementation will accept a certain value, so it must catch this exception. I am proposing that this exception should also be thrown by get methods (for all fields), because if an implementation uses lazy parsing, then there is no guarantee that the header value will parse correctly upon the invocation of the get method, and again this is implementation-dependent. > > > 2. A more general question - why do you have set methods at all in > the interfaces? The class that implements the interface can have set > methods but the interface itself does not need to have them. I have set methods in the interfaces because the objects will not only be coming up from the implementation - an application needs to be able to create and send requests, and this means being able to set the values. > Moreover, the parser has the job of setting up stuff in the returned > object. It has a set of BNF rules to decide on the correctness of the > arguments and it does not need for the class to re-implement the > check. For example, I think it ought to be the parser's job to check > if the q value is between 0 and 1. (Is the purpose of the set method > to allow for the application to do header formatting?) I absolutely agree that the parser should perform validation (hence the JainSipParseException) - but as I mentioned above there are certain basic criteria that must be met by all implementations and applications - I am using the IllegalArgumentException to cover these. Perhaps certain cases go too far in this validation - perhaps the IllegalArgumentException could be thrown only if a null argument is passed and all other validation is left up to the implementation's parser? (although a problem with certain cases such as PriorityHeader comes to mind, where the header values are defined as constants in the API and an IllegalArgumentException is thrown if any other value is passed - should we allow any non-null String values for the priority? Or to take your example of q-value above - should we just allow any non-null Float and let the parser enforce the 0-1 range? > > > >> >> >> (If it is considered acceptable to have a "null" subType then we >> should make it optional) >> >> > >> > >> > I don't quite follow the argument that lazy parsing "necessitates >> > throwing a parse exception for all get methods". Here is what I >> > had envisioned: >> > >> > >> > 1 When a message comes in it will be separated into headers based >> > on type. >> > 2 The header would be returned with no field initialized except the >> > text corresponding to the message. (this would necessitate >> > examining the first few bytes of the message to determine the >> > header type but the rest remains unparsed.) You can also stow away >> > the type information in the Header that is returned as well to know >> > which parser rule to invoke later. >> > 3. Later, when the application wants to parse the header, it has >> > the string corresponding to the message and can hand it off to the >> > parser, which can then fill in the appropriate fields corresponding >> > to the header. >> > 4. Subsequently, the application can access the fields just as an >> > eager parser based application would do. >> > >> > ( Where am I missing the boat with this? ) >> >> An application has no idea whether an implementation is using lazy >> or eager parsing - it is simply passed a header object - and then if >> it is interested in a particular field it calls the appropriate get >> method (which would internally invoke the parser in a lazy parsing >> implementation). So the application is completely oblivious to >> whether or not this "optimisation" is used by the implementation. > > > Ah! ( Why is this hiding of the implementation so important? ) Can > this be handled in the following fashion by an implementation: > > 1. The implementation keeps a flag in the class that implements the > interface whether the parsing has been done or not (i.e. boolean > parsingDone flag). > > 2. The Implementation keeps the entire string corresponding to the > header in the object. So the parser has to peek into the message > header to know what type the message is as soon as it has the header > string and then grabs the string and stores it away for lazy parsing. > > > 3. The get Method checks if the flag has been set, calls the parser > to do the parse if the flag has not been set and then returns a > parseException if the parse fails. This can be done transparently to > the caller. This is exactly what I would expect a lazy-parsing implementation to do - the fact that lazy-parsing is hidden from the application (except that the application must catch a JainSipParseException on the get methods to allow for the possibility that an implementation uses lazy-parsing - so technically the application will know that an implementation uses lazy-parsing if this exception is thrown by a get method - but I think the two cases are handled nicely by the addition of the exception) > > > > > > >> >> >> If the field is optional and does not exist in the header a >> ParameterNotSetException will be thrown by the implementation. > > A suggestion (shoot it down if it does not jive): > > 1. All fields are represented by objects (not simple types like int, > use Integer instead). I buy this part - then the IllegalArgumentException is only ever thrown if an object parameter is null, and the JainSipParseException is thrown for all other problems with the argument. > > 2. If the field is not set just return null See above for null discussion, > > > > >> If the field is mandatory and does not exist, a >> JainSipParseException will be thrown (header is malformed). If any >> header field is malformed a JainSipParseException is thrown. If a >> JainSipParseException is thrown, this indicates that the application >> must use the header's getValue method to get a string representation >> of the header value and do what it can with that. > > > Why the headers getValue ? Why is the string not part of the > Exception? Sure - we can say that the JainSipParseException's message must be the string value of the header. > > > >> >> >> > >> > >> > It appears that what is being attempted here (please correct me if >> > I am wrong) is to use exceptions as a mechanism to catch >> > un-initialized fields so the parser can be invoked in the exception >> > handler perhaps. This leads to a lot of overhead in clunky code. I >> > think it is a mistake to throw exceptions on every get to try to >> > protect the application from inadvertently accessing fields that >> > have not been initialized. Why not just assume that the >> > application must be smart enough to parse the header text before >> > accessing fields and not try to provide a complex mechanism as >> > above? >> >> >> We are using ParameterNotSetException for the case of an optional >> header not existing, and a JainSipParseException for the case of a >> malformed header being received from the network. >> >> If we assume the application is smart enough to do all header value >> parsing, we reduce a header to just being two strings - the type and >> value, which puts the burden of parsing on an application - this >> work can be done by the underlying implementation - doesn't it make >> more sense for an application to catch an exception than have to >> parse all header value strings (especially since this functionality >> already exists in the underlying stack) > > > No that is not what I had intended. Parser functionality exists in the > stack but has to be called explicitly by the implementation. Too much > hiding of the implementation from the application has its own set of > disadvantages (IMHO). I wanted parser fuctionality to be invoked implicitly by an application - from the API perspective it is an implementation detail - so the application should not be aware of how or when the underlying parser is invoked - it should just know that it is there in some form, and that if it tries to get or set a value that the implementation doesn't like it will get a JainSipParseException thrown back at it. This is important if we want to maintain the three core values of JAIN - portability, portability and portabilty ;) > > > > >> >> >> > >> > >> > >> > Regards, >> > >> > Ranga. >> > >> > Chris Harris wrote: >> > >> >> Erik, >> >> >> >> The implication of what you say is that all set methods in the >> >> header >> >> interfaces which take String arguments must throw a checked >> >> JainSipParseException. I think this is reasonable given that >> >> different >> >> implementations will be more tolerant than others. However, in >> >> order to allow >> >> lazy parsing by an implementation, all get methods in the header >> >> interfaces >> >> (regardless of return type) must throw a checked parse exception. >> >> This is a >> >> lot of checked exceptions - and will make life more awkward for >> >> the >> >> application developer. It would certainly be much less effort to >> >> not allow >> >> lazy parsing - there would be no need to throw a parse exception >> >> for all get >> >> methods - greatly reducing the number of checked exceptions. >> >> Unfortunately it >> >> has been said that JAIN SIP support for lazy parsing is a must. >> >> If it is then >> >> I guess there is no other choice than to include the exceptions? >> >> >> >> Regards, >> >> Chris >> >> >> >> Erik Nissen wrote: >> >> >> >> > Chris Harris wrote: >> >> > >> >> > > >> >> > > We need to decide whether this should be a checked or runtime >> >> exception. >> >> > >> >> > The rule of thumb is to use: >> >> > * checked exceptions when the program should handle situations >> >> which >> >> > can/will occur. >> >> > * runtime exceptions when there are programming error (God >> >> forbid :-) >> >> > >> >> > So: >> >> > Parse errors should throw checked exceptions. >> >> > Becaurse parse errors are outside the control of the programmer >> >> >> >> > and he/she should be forced to handle such conditions in the >> >> code. >> >> > >> >> > Null/wrong arguments should throw runtime exceptions. >> >> > >> >> > If it is possible, reduce the number of methods throwing >> >> (checked) >> >> > exceptions >> >> > to a minimum. >> >> > >> >> > Best regards, >> >> > /Erik Nissen, >> >> > Ericsson Utveckling AB >> >> >> >> _______________________________________________ >> >> SIP mailing list >> >> SIP@lists.bell-labs.com >> >> http://lists.bell-labs.com/mailman/listinfo/sip >> > >> > -- >> > M.Ranganathan >> > NIST Advanced Networking Technologies Group, >> > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. >> > Tel: 301 975 3664 Fax: 301 590 0932 >> > >> > >> > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > --------------411948D645674E2B35A78E41 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ranga,

My comments are in red...

Chris
 

"M. Ranganathan" wrote:

Chris,

Thanks for the prompt response.  Hope you had a great Thanksgiving.

I wish there was such a thing as Thanksgiving in Ireland :(
 

My followup is below. ( in blue)

Regards

Ranga.

Chris Harris wrote:

Ranga,

See comments below.

Regards,
Chris

"M. Ranganathan" wrote:

 
Chris, Erik,

While we are on the subject of Exceptions, why do null arguments throw runtime exceptions when you do a get on them? For example, in the Accept interface, getContentSubtype throws a IllegalArgumentException if  is null. IMHO, I think it is valid to have a null subtype so why not just return null rather than throw exception here?

By a "doing a get on a null argument" here I assume you mean attempting to get a non-existent optional field? If you do this a checked ParameterNotSetException is thrown, not a runtime exception.


Yes. Thats what I had meant.  The word "argument" should have been "field".   Why do you need a  ParameterNotSet exception in this case?  Are you trying to handle the case of basic types like integers, floats and so on ? For objects, null is synonymous with not set isnt it?

We discussed this matter in depth at the last JAIN SIP meeting in October, and we came to the conclusion that getting and setting null values is not a good idea for several reasons e.g. it is easier to debug a ParameterNotSetException than searching for the source of a later NullPointerException, and it forces the application to allow for the fact that there is a reasonable chance that a particular field does not exist. [Of course, if we did allow the use of null, we could cut down on the number of methods and drop the ParameterNotSetException - but  is it really worth sacrificing clarity and robustness for the sake of cutting down on API size?]
 
 

There are two approaches to handling optional header parts. One approach is to allow the passing and returning of null objects from get and set methods (implicit "remove" and "has"), and the other is to explicitly add has and remove methods (and exceptions on the set and get methods). As for mandatory header parts - I think passing null to a set method should definitely throw an IllegalArgumentException.

I have the following questions about setXXX methods:

1.  Why do you restrict throwing IllegalArgumentException to only null arguments in some of the headers? Why are you not checking for proper formatting of the passed arguments (by giving it to the parser for example and running the appropriate  parser rule).

In general, an IllegalArgumentException is thrown if an argument to a set method fails basic validation (i.e. no implementation-specific parsing is used). Note that an application can ensure that this exception is not thrown by following the rules defined in the API . So if an argument is a String, I throw an IllegalArgumentException if the argument is null or zero-length.

Of course this is not sufficient validation and the string must be parsed to check for whitespaces, newlines etc, and different implementations will be more tolerant than others. This is why there is a checked JainSipParseException - an application cannot tell in advance if a particular implementation will accept a certain value, so it must catch this exception.

I am proposing that this exception should also be thrown by get methods (for all fields), because if an implementation uses lazy parsing, then there is no guarantee that the header value will parse correctly upon the invocation of the get method, and again this is implementation-dependent.

 

2.  A more general question - why do you have set methods at all in the interfaces?  The class that implements the interface can have set methods but the interface itself does not need to have them.

I have set methods in the interfaces because the objects will not only be coming up from the implementation - an application needs to be able to create and send requests, and this means being able to set the values.
 Moreover, the parser has the job of setting up stuff in the returned object. It has a set of BNF rules to decide on the correctness of the arguments and it does not need for the class to re-implement the check. For example, I think it ought to be the parser's job to check if the q value is between 0 and 1.   (Is the purpose of the set method to allow for the application to do header formatting?)
I absolutely agree that the parser should perform validation (hence the JainSipParseException) - but as I mentioned above there are certain basic criteria that must be met by all implementations and applications - I am using the IllegalArgumentException to cover these. Perhaps certain cases go too far in this validation - perhaps the IllegalArgumentException could be thrown only if a null argument is passed and all other validation is left up to the implementation's parser? (although a problem with certain cases such as PriorityHeader comes to mind, where the header values are defined as constants in the API and an IllegalArgumentException is thrown if any other value is passed - should we allow any non-null String values for the priority? Or to take your example of q-value above - should we just allow any non-null Float and let the parser enforce the 0-1 range?
 
 
 
 

(If it is considered acceptable to have a "null" subType then we should make it optional)

 

I don't quite follow the argument that lazy parsing  "necessitates throwing a parse exception for all get methods".   Here is what I had envisioned:
 

1 When a message comes in it will be separated into headers based on type.
2 The header would be returned with no field initialized except the text corresponding to the message. (this would necessitate examining the first few bytes of the message to determine the header type but the rest remains unparsed.) You can also stow away the type information in the Header that is returned as well to know which parser rule to invoke later.
3. Later, when the application wants to parse the header, it has the string corresponding to the message and can hand it off to the parser, which can then fill in the appropriate fields corresponding to the header.
4. Subsequently, the application can access the fields just as an eager parser based application would do.

( Where am I missing the boat with this? )

An application has no idea whether an implementation is using lazy or eager parsing - it is simply passed a header object - and then if it is interested in a particular field it calls the appropriate get method (which would internally invoke the parser in a lazy parsing implementation). So the application is completely oblivious to whether or not this "optimisation" is used by the implementation.


Ah! ( Why is this hiding  of the implementation so important? )  Can this be handled in the following fashion by an implementation:

1. The implementation keeps a flag in the  class that implements the interface whether the parsing has been done or not (i.e. boolean parsingDone flag).

2. The Implementation keeps the entire string corresponding to the header in the object. So the parser has to peek into the message header to know what type the message is as soon as it has the  header string and then grabs the string and stores it away for lazy parsing.
 

3. The get Method  checks if the flag has been set, calls the parser to do the parse if the flag has not been set and then returns a parseException if the parse fails. This can be done transparently to the caller.

This is exactly what I would expect a lazy-parsing implementation to do - the fact that lazy-parsing is hidden from the application (except that the application must catch a JainSipParseException on the get methods to allow for the possibility that an implementation uses lazy-parsing - so technically the application will know that an implementation uses lazy-parsing if this exception is thrown by a get method - but I think the two cases are handled nicely by the addition of the exception)
 
 
 
 
 
 

If the field is optional and does not exist in the header a ParameterNotSetException will be thrown by the implementation.

A suggestion (shoot it down if it does not jive):

1. All fields are represented by objects (not simple types like int, use Integer instead).

I buy this part - then the IllegalArgumentException is only ever thrown if an object parameter is null, and the JainSipParseException is thrown for all other problems with the argument.
 
2. If the field is not set just return null
See above for null discussion,
 
 
 
If the field is mandatory and does not exist, a JainSipParseException will be thrown (header is malformed). If any header field is malformed a JainSipParseException is thrown. If a JainSipParseException is thrown, this indicates that the application must use the header's getValue method to get a string representation of the header value and do what it can with that.


Why the headers getValue ? Why is the string not part of the Exception?

Sure - we can say that the JainSipParseException's message must be the string value of the header.
 
 
 
 

It appears that what is being attempted here (please correct me if I am wrong) is to use exceptions as a mechanism to catch un-initialized fields so the parser can be invoked in the exception handler perhaps. This leads to a lot of overhead in clunky code. I think it is a mistake to throw exceptions on every get to try to protect the application from inadvertently accessing fields that have not been initialized.  Why not just assume that the application must be smart enough to parse the header text before accessing fields and not try to provide a complex mechanism as above?


We are using ParameterNotSetException for the case of an optional header not existing, and a JainSipParseException for the case of a malformed header being received from the network.

If we assume the application is smart enough to do all header value parsing, we reduce a header to just being two strings - the type and value, which puts the burden of parsing on an application - this work can be done by the underlying implementation - doesn't it make more sense for an application to catch an exception than have to parse all header value strings (especially since this functionality already exists in the underlying stack)


No that is not what I had intended. Parser functionality exists in the stack but has to be called explicitly by the implementation. Too much hiding of the implementation from the application has its own set of disadvantages (IMHO).

I wanted parser fuctionality to be invoked implicitly by an application - from the API perspective it is an implementation detail - so the application should not be aware of how or when the underlying parser is invoked - it should just know that it is there in some form, and that if it tries to get or set a value that the implementation doesn't like it will get a JainSipParseException thrown back at it. This is important if we want to maintain the three core values of JAIN - portability, portability and portabilty ;)
 
 
 
 
 
 

Regards,

Ranga.

Chris Harris wrote:

Erik,

The implication of what you say is that all set methods in the header
interfaces which take String arguments must throw a checked
JainSipParseException. I think this is reasonable given that different
implementations will be more tolerant than others. However, in order to allow
lazy parsing by an implementation, all get methods in the header interfaces
(regardless of return type) must throw a checked parse exception. This is a
lot of checked exceptions - and will make life more awkward for the
application developer. It would certainly be much less effort to not allow
lazy parsing - there would be no need to throw a parse exception for all get
methods - greatly reducing the number of checked exceptions. Unfortunately it
has been said that JAIN SIP support for lazy parsing is a must. If it is then
I guess there is no other choice than to include the exceptions?

Regards,
Chris

Erik Nissen wrote:

> Chris Harris wrote:
>
> >
> > We need to decide whether this should be a checked or runtime exception.
>
> The rule of thumb is to use:
> * checked exceptions when the program should handle situations which
> can/will occur.
> * runtime exceptions when there are programming error (God forbid :-)
>
> So:
> Parse errors should throw checked exceptions.
> Becaurse parse errors are outside the control of the programmer
> and he/she should be forced to handle such conditions in the code.
>
> Null/wrong arguments should throw runtime exceptions.
>
> If it is possible, reduce the number of methods throwing (checked)
> exceptions
> to a minimum.
>
> Best regards,
> /Erik Nissen,
> Ericsson Utveckling AB

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

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
 
-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
 
--------------411948D645674E2B35A78E41-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 10: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 KAA13897 for ; Mon, 27 Nov 2000 10:30:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6550F44350; Mon, 27 Nov 2000 09:30:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 294A244336 for ; Mon, 27 Nov 2000 09:29:28 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eARFT0Y15519; Mon, 27 Nov 2000 09:29:00 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eARFQUT25023; Mon, 27 Nov 2000 09:26:30 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA22223; Mon, 27 Nov 2000 09:28:59 -0600 (CST) Message-ID: <3A221A05.BECD85DC@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Jonathan Rosenberg , "'Jo Hornsby'" , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) References: <3A20D66E.EAE34429@ericsson.com> <20001127001509.C24967@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: Mon, 27 Nov 2000 09:23:34 +0100 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > Sean Olson (sean.olson@ericsson.com): > > > > 1. non SIP URLs in request URI > > > > > > We can either define record-route parameters, or else make sure that > > > the URL put into the record route is a sip url. I originally propose > > > RR parameters, but I think insisting on a SIP URL is backwards > > > compatible and more reasonable. That seems to be consensus. > > > > Please do not make this mistake. If we don't require a SIP URL in the > > Request-URI, the From, the To, or even the Contact, then why mandate > > it in the Record-Route:? > > Do you want Record-Route and Contact header parameters indicating the > IP address and port to send the request? I would be happy with that. > > > I don't mind non-SIP URLs, but I do mind new parameters: they just > provide a false sense of security that things will magically work. If > you put a non-SIP URL in the Contact or Record-Route or Request-URI, you > had better know for sure that whomever is going to process the message > knows how to forward it on its own. Hmmm. Sort of like using a non-SIP URL in say, the To/From/Contact ... If we can't use parameters for things like this, then why do we have parameters at all??? (I mean parameters on the RR) > > > Non-SIP URLs in the To/From don't matter because Contact is now > mandatory pretty much everywhere. You don't need to look at the From to > route messages. > But the To/From is there for a reason. At a transaction level, I am all for treating them as opaque strings. Higher up in the application strata, these should have some meaning besides just strings -- at least there should be the possibility for these to have meaning. -- 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 Nov 27 11: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 SMTP id LAA29034 for ; Mon, 27 Nov 2000 11:16:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EEBFA44344; Mon, 27 Nov 2000 10:16:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 068E644336 for ; Mon, 27 Nov 2000 10:15:20 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 27 Nov 2000 10:14:58 -0600 (CST) From: Billy Biggs To: Sean Olson Cc: Jonathan Rosenberg , Jo Hornsby , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <20001127101457.A25585@div8.net> References: <3A20D66E.EAE34429@ericsson.com> <20001127001509.C24967@div8.net> <3A221A05.BECD85DC@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A221A05.BECD85DC@ericsson.com>; from sean.olson@ericsson.com on Mon, Nov 27, 2000 at 09:23:34AM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 27 Nov 2000 10:14:58 -0600 Sean Olson (sean.olson@ericsson.com): >>>> 1. non SIP URLs in request URI >> >> Do you want Record-Route and Contact header parameters indicating >> the IP address and port to send the request? > > I would be happy with that. > >> I don't mind non-SIP URLs, but I do mind new parameters: they just >> provide a false sense of security that things will magically work. >> If you put a non-SIP URL in the Contact or Record-Route or >> Request-URI, you had better know for sure that whomever is going to >> process the message knows how to forward it on its own. > > Hmmm. Sort of like using a non-SIP URL in say, the To/From/Contact ... > If we can't use parameters for things like this, then why do we have > parameters at all??? (I mean parameters on the RR) Sorry, let me be more specific. Say I use a non-SIP URI in the RR (or Contact) of: ;raddr=udp/22.33.44.55:5060 My only choice for request-URI is "tel:911", but this does not convey the destination of the request. Since you now can't route based on request-URI, you can't use an outbound proxy, stuff breaks in general. Now, what if I have a cluster of proxies which all route messages internally using tel URIs. I have no problem with this, and placing these non-SIP URIs in the RR totally makes sense. But I see two issues: 1. Should the spec instruct UAs to copy RR parameters into the Route, so that the raddr can be useful within this cluster? I think yes, definitely. This is cheap and useful. 2. Should we standardize an raddr RR parameter and allow this to be used for SIP URIs? I say no. In general this technique breaks with outbound proxies or transparent proxies. If necessary, this could be standardized outside of the SIP spec. I got the impression earlier that you were looking for point 2 to be in the spec. >> Non-SIP URLs in the To/From don't matter because Contact is now >> mandatory pretty much everywhere. You don't need to look at the >> From to route messages. > > But the To/From is there for a reason. At a transaction level, I am > all for treating them as opaque strings. Higher up in the application > strata, these should have some meaning besides just strings -- at > least there should be the possibility for these to have meaning. Totally, but a client should know to convert a tel URI to a SIP URI like phonenumber@gateway. I thought that was the point of them, not to use them as a Request-URI. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 12: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 MAA11374 for ; Mon, 27 Nov 2000 12:01:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA6DD44355; Mon, 27 Nov 2000 11:01:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web11006.mail.yahoo.com (web11006.mail.yahoo.com [216.136.131.56]) by lists.bell-labs.com (Postfix) with SMTP id E02CB4437C for ; Mon, 27 Nov 2000 10:39:32 -0500 (EST) Message-ID: <20001127162931.15402.qmail@web11006.mail.yahoo.com> Received: from [47.230.0.41] by web11006.mail.yahoo.com; Mon, 27 Nov 2000 08:29:31 PST From: Brian S To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] What SIP doesn't tell you how to do. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 08:29:31 -0800 (PST) Apparently SIP doesn't tell you how to do any of the following as well: 1. Be professional. 2. Show others common courtesy. 3. Switch to decaf. BTW- He never asked how to do anything, just if it could be done. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, November 22, 2000 10:59 AM To: 'Sanjiv Deshpande'; sip@lists.bell-labs.com Subject: RE: [SIP] multiple location SIP is just a protocol. Thats it. Its a tool. If you want device A to call device B, it tells you how to do that. Like all tools, you can use them in many different ways. When you buy a hammer in Home Depot, does it tell you whether to use your left hand or right? How many fingers to grip with it? The size of the nails to use with it? Of course not. However, for some reason that I cannot fathom, many people seem to believe the opposite is true for protocols; that is, protocols need to insist on how syntax and semantics AND how they are applied to solve real world problems. This approach just results in systems that are useful to no one. Would you buy a hammer that said "for nails of length 1 inch only?" I doubt it. So, to be specific, SIP doesn't tell you how to do any of the following: 1. the color of the phones that use SIP 2. the GUI for SIP calls 3. how you build a network of proxy servers 4. whether a phone can make calls while its in a call 5. qualifications for human beings to make use of SIP softphones (i.e., IQ levels, height, or what have you). 6. how many simultaneous calls the device can be in Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Sanjiv Deshpande [mailto:sdeshpan@telcordia.com] > Sent: Wednesday, November 22, 2000 11:36 AM > To: sip@lists.bell-labs.com > Subject: [SIP] multiple location > > > > > > > Q: > INVITE Sent by UAC got forked and reached two UAS1 and UAS2 , > the UAC decided > to talk to UAS1. Is it possible that UAS2 (Assuming it is a > client also) can > make a call to someone else. > > > What I wanted to know is, A user can be contacted at multiple > location if one of > the location answers a CALL is it possible for somebody else > on behalf of that > user make CALLS or receive CALLS.... > > > Thanks > Sanjiv. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 12:08: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 MAA12842 for ; Mon, 27 Nov 2000 12:08:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 22CC84437C; Mon, 27 Nov 2000 11:08:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id AFC9844378 for ; Mon, 27 Nov 2000 11:07:08 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eARH5hY13462; Mon, 27 Nov 2000 11:06:40 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id LAA23121; Mon, 27 Nov 2000 11:05:41 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA29349; Mon, 27 Nov 2000 11:05:40 -0600 (CST) Message-ID: <3A2230AE.15F53735@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Jonathan Rosenberg , Jo Hornsby , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) References: <3A20D66E.EAE34429@ericsson.com> <20001127001509.C24967@div8.net> <3A221A05.BECD85DC@ericsson.com> <20001127101457.A25585@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: Mon, 27 Nov 2000 11:00:14 +0100 Content-Transfer-Encoding: 7bit > Sorry, let me be more specific. Say I use a non-SIP URI in the RR (or > Contact) of: > > ;raddr=udp/22.33.44.55:5060 > > My only choice for request-URI is "tel:911", but this does not convey > the destination of the request. Since you now can't route based on > request-URI, you can't use an outbound proxy, stuff breaks in general. Why doesn't the outbound proxy RR? > > Now, what if I have a cluster of proxies which all route messages > internally using tel URIs. I have no problem with this, and placing > these non-SIP URIs in the RR totally makes sense. But I see two issues: > > 1. Should the spec instruct UAs to copy RR parameters into the Route, > so that the raddr can be useful within this cluster? > > I think yes, definitely. This is cheap and useful. > Agreed > > 2. Should we standardize an raddr RR parameter and allow this to be > used for SIP URIs? > > I say no. In general this technique breaks with outbound proxies > or transparent proxies. If necessary, this could be standardized > outside of the SIP spec. Standardizing this as an extension doesn't really help. I'm curious why transparent proxies would be in the signalling path. Outbound proxies should RR (am I missing something here?) > > I got the impression earlier that you were looking for point 2 to be > in the spec. That was my intention. > > > >> Non-SIP URLs in the To/From don't matter because Contact is now > >> mandatory pretty much everywhere. You don't need to look at the > >> From to route messages. > > > > But the To/From is there for a reason. At a transaction level, I am > > all for treating them as opaque strings. Higher up in the application > > strata, these should have some meaning besides just strings -- at > > least there should be the possibility for these to have meaning. > > Totally, but a client should know to convert a tel URI to a SIP URI > like phonenumber@gateway. I thought that was the point of them, not to > use them as a Request-URI. In this specific case, it may or may not be possible for the UAC to translate the tel: URI into a SIP URI. (How does the client know which "domain" owns a specific number?) This is where an outbound proxy may play a role. In any case, it may be useful in certain cases to use a Request-URI which is not directly routable. A proxy downstream can translate this into a Request-URI which is routable. I see no good reason to make an arbitrary limitation of the RR to SIP URLs. Is there an intractable problem here that I am missing? It is Monday after all :) > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com -- 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 Nov 27 12:30:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20887 for ; Mon, 27 Nov 2000 12:30:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 193134433D; Mon, 27 Nov 2000 11:30:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 46C1F44336 for ; Mon, 27 Nov 2000 11:29:32 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 27 Nov 2000 11:28:50 -0600 (CST) From: Billy Biggs To: Sean Olson Cc: Jonathan Rosenberg , Jo Hornsby , hgs@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <20001127112850.A25698@div8.net> References: <3A20D66E.EAE34429@ericsson.com> <20001127001509.C24967@div8.net> <3A221A05.BECD85DC@ericsson.com> <20001127101457.A25585@div8.net> <3A2230AE.15F53735@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A2230AE.15F53735@ericsson.com>; from sean.olson@ericsson.com on Mon, Nov 27, 2000 at 11:00:14AM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 27 Nov 2000 11:28:50 -0600 Sean Olson (sean.olson@ericsson.com): >> Sorry, let me be more specific. Say I use a non-SIP URI in the RR >> (or Contact) of: >> >> ;raddr=udp/22.33.44.55:5060 >> >> My only choice for request-URI is "tel:911", but this does not >> convey the destination of the request. Since you now can't route >> based on request-URI, you can't use an outbound proxy, stuff breaks >> in general. > > Why doesn't the outbound proxy RR? It does, but what if you call me directly and not through my outbound proxy? The INVITE transaction completes without my outbound proxy being placed in the Route. When I send a BYE or whatever, it will go to the outbound proxy, and now your URI loses its significance. That's very brittle. >> 2. Should we standardize an raddr RR parameter and allow this to >> be used for SIP URIs? >> >> I say no. In general this technique breaks with outbound >> proxies or transparent proxies. If necessary, this could be >> standardized outside of the SIP spec. > > Standardizing this as an extension doesn't really help. I'm curious > why transparent proxies would be in the signalling path. Outbound > proxies should RR (am I missing something here?) Transparent proxies are useful when you want to divert SIP requests going out to the internet to go to a special firewall proxy. This is common with HTTP. SIP and HTTP are elegant in their proxy-awareness. Messages can be forwarded between proxies without information loss. However, with an raddr or whatever, now the IP layer has significance to the meaning of the message, which breaks the model. >> [...] but a client should know to convert a tel URI to a SIP URI >> like phonenumber@gateway. I thought that was the point of them, >> not to use them as a Request-URI. > > In this specific case, it may or may not be possible for the UAC to > translate the tel: URI into a SIP URI. (How does the client know which > "domain" owns a specific number?) This is where an outbound proxy may > play a role. In any case, it may be useful in certain cases to use a > Request-URI which is not directly routable. A proxy downstream can > translate this into a Request-URI which is routable. [...] But now the client and the outbound proxy are together acting as a single logical client. This technique, translating a tel: URI into a SIP URI, can only be done at the edges, and does not work unless you are sure you are not going to hit some transparent proxy in the middle. My point is that URI schemes other than SIP are useful for internal purposes. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 13:42:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22160 for ; Mon, 27 Nov 2000 13:42:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B5DCB44343; Mon, 27 Nov 2000 12:42:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from godzilla.ipdialog.com (ipsniffers-122.fiasj.net [208.238.222.122]) by lists.bell-labs.com (Postfix) with ESMTP id 9239344336 for ; Mon, 27 Nov 2000 12:41:43 -0500 (EST) 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 KAA25566; Mon, 27 Nov 2000 10:41:33 -0800 Message-ID: <3A22AADC.6EC40BF4@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: Jonathan Rosenberg Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 27 Nov 2000 10:41:32 -0800 Content-Transfer-Encoding: 7bit Jonathan and Henning, I think this is a great shot at tunneling SIP and RTP through Firewalls, though you may want to add the following caveats to section 6: 1) Wrt corporate tunneling, high-bandwidth voice traffic has a distinct network signature vs. (relatively) low-bandwidth Web traffic. If you blast voice traffic, encrypted or unencrypted over Web ports, it's going to stick out like a sore thumb even using the crudest network monitoring tools. ISS and the other network intrusion detection packages may even flag it as a Netbus, BackOrifice, or Distributed Denial of Service attack signature. Most network administrators will shut the originating host/port down immediately and ask questions later. 2) The Internet backbone itself has been heavily optimized (some might say almost too optimized) for port 80 traffic, and is moving in that direction (as much as is feasible) for port 443/HTTPS. Increasingly, ISPs are using Web caching engines to limit this traffic across their backbones. Case in point--I used Checkpoint's encrypted VPN product in a previous company to connect an overseas location to our site (encrypted payloads, port numbers stay the same). Our remote site wanted to access our internal Web server. Unfortunately, one of the intermediate ISPs was using a Web caching product, which resulted in the caching engine intercepting, then attempting to originate an (unauthorized) port 80 access to our internal Web server on the remote end's behalf, with the expected (non)result. The answer from the ISP was, of course, "well it works fine for all our normal customers--EOM". I think you'd see some very interesting side effects if you applied a tunneled RTP stream to this or other kinds of caching servers on port 80. Granted, 443/SSL-caching is a much more difficult problem, equating to a man-in-the- middle attack--maybe even unsolvable, but given the monetary inceptive is huge to come up with a solution here too, partial or otherwise.... Howard Hart ipDialog, Inc. Jonathan Rosenberg wrote: > I wanted to draw attention to the following draft which we have submitted. > It tackles, and provides what we believe to be at least a workable solution, > to the problem of SIP traversal through enterprise firewalls and NATs when > there is no ALG at all associated with, or inside of, the firewall. > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, November 22, 2000 6:13 AM > To: IETF-Announce > Cc: sip@lists.bell-labs.com > Subject: I-D ACTION:draft-rosenberg-sip-entfw-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SIP Traversal through Residential and Enterprise > NATs > and Firewalls > Author(s) : J. Rosenberg, H. Schulzrinne > Filename : draft-rosenberg-sip-entfw-00.txt > Pages : 15 > Date : 21-Nov-00 > > In this draft, we discuss how SIP can traverse enterprise and > residential firewalls and NATs. This environment is challenging > because we assume here that the end user has little or no control > over the firewall or NAT, and that the firewall or NAT is completely > ignorant of SIP > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-rosenberg-sip-entfw-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-rosenberg-sip-entfw-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > Subject: > Date: Wed, 22 Nov 2000 14:05:37 -0500 > > ------------------------------------------------------------------------ > > ATT04220.txtName: ATT04220.txt > Type: Plain Text (text/plain) > > Access-Type: anon-ftp > Document Info: Site: internet-drafts > Mode: ftp.ietf.org _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 14:32: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 OAA10363 for ; Mon, 27 Nov 2000 14:32:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A97544378; Mon, 27 Nov 2000 13:32:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id B4F5844360 for ; Mon, 27 Nov 2000 13:31:09 -0500 (EST) Received: from Pradeep (w040.z208176180.sjc-ca.dsl.cnc.net [208.176.180.40]) by westhost16.westhost.net (8.8.5/8.8.5) with SMTP id NAA31509; Mon, 27 Nov 2000 13:36:22 -0600 From: "Tom Tang" To: Cc: 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] SIP Security Abstract Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 11:35:06 -0800 Content-Transfer-Encoding: 7bit Hello Everyone: I would like initiate some type of action in this WG on addressing security for SIP. Everyone knows that its an important topic, but so far little has been done. I have written a short and very high level problem statement to try and provide a start for these discussions. End-To-End Security For SIP SIP messages can/might traverse N proxies between the sender and the destination. Each proxy along this path has "promised" to provide some service to messages it receives (We will address this idea of a promise in the lower paragraph). However, in order to provide this service, the proxy might need to modify/access the SIP payload. So while we the sender want to provide enough information to the proxy so that they can provide this service, we also do not want to expose our message in entirety. How do we do this ? The SIP draft has mentioned using underlying security mechanisms, but the adaptations of these are not discussed in enough detail. For example, IPSec does not know how to operate on partial payloads. Proxy Services SIP proxies essentially provide a service to messages they receive. However, how do we know that these proxies are actually trusted ? Or better yet, how do we know that a specific proxy is trusted to provide a certain service ? The common answer would be to integrate PKI into the SIP infrastructure, but would that be deployable ? Plan ? Security is an issue which requires detailed addressing before mass acceptance. Additional requirements would be compatibility with existing infrastructure, latency, costs, and possibly CALEA. I would like to propose that at the next IETF, this body start addressing security seriously. A trust model would be an ideal starting point. Cheers, - Tom Tang Tom Tang Systems Software Architect IP Unity 1575 McCandless Drive Milpitas, CA 95035 (408) 957-0800 x154 (w) (408) 957-0823 (f) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 14:43: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 OAA13963 for ; Mon, 27 Nov 2000 14:43:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C88F44438C; Mon, 27 Nov 2000 13:43:09 -0500 (EST) 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 5BFC744375 for ; Mon, 27 Nov 2000 13:42:05 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA27336 for ; Mon, 27 Nov 2000 12:41:41 -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 MAA04553 for ; Mon, 27 Nov 2000 12:41:41 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 27 Nov 2000 13:41:38 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED86E1@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Session progress Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 13:41:37 -0600 Hi 1) Bis 4.2.1 says: "A UAC MUST be prepared to receive media data according to the session description as soon as it sends an INVITE (or re-INVITE) " 2) According the 183 draft that there must be first a two way path established (or at least the UAC should get first the UAS RTP information) before the UAC is able to get Alerting/call treatment RTP packets. I guess (2) overrides (1) (and is even included in 1 now) My question is: Why is the need to have the two way path established for being able to convey the RTP information from the UAS to the UAC? Thanks Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 15:28: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 PAA26502 for ; Mon, 27 Nov 2000 15:28:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82CD54435A; Mon, 27 Nov 2000 14:28:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-60.antd.nist.gov [129.6.60.251]) by lists.bell-labs.com (Postfix) with ESMTP id 97E9944336 for ; Mon, 27 Nov 2000 14:27:02 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id PAA07254; Mon, 27 Nov 2000 15:21:49 -0500 (EST) Message-ID: <3A22C387.BF280383@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: jainsip@sun.com, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A16922C.EFDE9019@ericsson.com> <3A1A5BAC.A0975580@dynamicsoft.com> <3A1DC4BD.533272E6@nist.gov> <3A1E82FB.DA1FC1AC@dynamicsoft.com> <3A1E8DEE.EA2DACA0@nist.gov> <3A22781D.901412E0@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------E5356573E9C4502DE8749499" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 15:26:47 -0500 --------------E5356573E9C4502DE8749499 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Chris, Thanks for the prompt response. Not to drag this on for ever, but I have a few more suggestions in followup to your comments/clarifications (in blue below). As you are in Ireland, your missiles cannot reach me so I can be bold :) Regards Ranga. A design issue not discussed below: Whenever there is more than one header to be returned (via headers for example), you return an array. An array is easy to walk through. However, I would think it more useful to return a collection of some sort that supports additional methods such as checking if an address exists in the list of headers returned etc. That might be of some use to an implementation. If you define the returned type as an array of headers, there is no way to extend the class to support additional functionality. May I suggest adding a collection class interface for collections of SIP Headers (and that can be specialized by implementations to support additional query methods etc.), say something like SIPHeaderList Chris Harris wrote: > Ranga, > > My comments are in red... > > Chris > > > "M. Ranganathan" wrote: > >> Chris, >> >> Thanks for the prompt response. Hope you had a great Thanksgiving. > > I wish there was such a thing as Thanksgiving in Ireland :( > >> >> >> My followup is below. ( in blue) >> >> Regards >> >> Ranga. >> >> Chris Harris wrote: >> >> > Ranga, >> > >> > See comments below. >> > >> > Regards, >> > Chris >> > >> > "M. Ranganathan" wrote: >> > >> >> >> >> Chris, Erik, >> >> >> >> While we are on the subject of Exceptions, why do null arguments >> >> throw runtime exceptions when you do a get on them? For example, >> >> in the Accept interface, getContentSubtype throws a >> >> IllegalArgumentException if is null. IMHO, I think it is valid >> >> to have a null subtype so why not just return null rather than >> >> throw exception here? >> > >> > By a "doing a get on a null argument" here I assume you mean >> > attempting to get a non-existent optional field? If you do this a >> > checked ParameterNotSetException is thrown, not a runtime >> > exception. >> >> >> Yes. Thats what I had meant. The word "argument" should have been >> "field". Why do you need a ParameterNotSet exception in this >> case? Are you trying to handle the case of basic types like >> integers, floats and so on ? For objects, null is synonymous with >> not set isnt it? > > We discussed this matter in depth at the last JAIN SIP meeting in > October, and we came to the conclusion that getting and setting null > values is not a good idea for several reasons e.g. it is easier to > debug a ParameterNotSetException than searching for the source of a > later NullPointerException, and it forces the application to allow for > the fact that there is a reasonable chance that a particular field > does not exist. [Of course, if we did allow the use of null, we could > cut down on the number of methods and drop the > ParameterNotSetException - but is it really worth sacrificing clarity > and robustness for the sake of cutting down on API size?] Well, I guess that is a judgement call. With this design, you may have code that is cluttered with a lot of exception handlers and the API is quite big. Checking for null is fairly standard (am I giving my age away ? :) and I can see at least a few places in the base JAVA API where null is returned to denote empty and anyway, the app has a good old stack trace to rely on to see the source of the exception when null pointers are encountered. Guarding an application from null pointer exception is pretty hard anyway so why complicate the API to handle this one case? ( For collections of SIPHeaders, you can check for empty collection and you will not have this problem. ) > > >> >> >> > >> > >> > There are two approaches to handling optional header parts. One >> > approach is to allow the passing and returning of null objects from >> > get and set methods (implicit "remove" and "has"), and the other is >> > to explicitly add has and remove methods (and exceptions on the set >> > and get methods). As for mandatory header parts - I think passing >> > null to a set method should definitely throw an >> > IllegalArgumentException. >> >> I have the following questions about setXXX methods: >> >> 1. Why do you restrict throwing IllegalArgumentException to only >> null arguments in some of the headers? Why are you not checking for >> proper formatting of the passed arguments (by giving it to the >> parser for example and running the appropriate parser rule). > > In general, an IllegalArgumentException is thrown if an argument to a > set method fails basic validation (i.e. no implementation-specific > parsing is used). Note that an application can ensure that this > exception is not thrown by following the rules defined in the API . So > if an argument is a String, I throw an IllegalArgumentException if the > argument is null or zero-length. > > Of course this is not sufficient validation and the string must be > parsed to check for whitespaces, newlines etc, and different > implementations will be more tolerant than others. This is why there > is a checked JainSipParseException - an application cannot tell in > advance if a particular implementation will accept a certain value, so > it must catch this exception. > > I am proposing that this exception should also be thrown by get > methods (for all fields), because if an implementation uses lazy > parsing, then there is no guarantee that the header value will parse > correctly upon the invocation of the get method, and again this is > implementation-dependent. > >> >> >> 2. A more general question - why do you have set methods at all in >> the interfaces? The class that implements the interface can have >> set methods but the interface itself does not need to have them. > > I have set methods in the interfaces because the objects will not only > be coming up from the implementation - an application needs to be able > to create and send requests, and this means being able to set the > values. Ah! My understanding was correct then. OK. Perhaps this would be too much of a change for you to consider but let me make a suggestion anyway .... I think formatting headers should be considered under a different set of API. Here is what I am suggesting 1. Get rid of the setXXX interfaces (the parser will have direct access to the classes and does not need them and it will cut down the size of the API). 2. Have a SIPMessageFormatter interface who'se sole job it is to format output messages. This can have methods to format the different outgoing messages and will throw parse exceptions if the strings that it gets are incorrect. The MessageFormatter interface takes as parameter values only Strings. Concretely, for example: public interface SIPMessageFormatter { public String createFromMessage( String from , String tag) throws SIPParseException; ..................... } It would be slower for an implementation to extract the same information out of a structure and hand it to a parser for validation (IMHO). A "loose implementation" may not want to be bothered with validation at all and leave it to the reciever to reject the mesage, thereby making the implementation faster or it may do very cursory checking. > > >> Moreover, the parser has the job of setting up stuff in the >> returned object. It has a set of BNF rules to decide on the >> correctness of the arguments and it does not need for the class to >> re-implement the check. For example, I think it ought to be the >> parser's job to check if the q value is between 0 and 1. (Is the >> purpose of the set method to allow for the application to do header >> formatting?) > > I absolutely agree that the parser should perform validation (hence > the JainSipParseException) - but as I mentioned above there are > certain basic criteria that must be met by all implementations and > applications - I am using the IllegalArgumentException to cover these. > Perhaps certain cases go too far in this validation - perhaps the > IllegalArgumentException could be thrown only if a null argument is > passed and all other validation is left up to the implementation's > parser? (although a problem with certain cases such as PriorityHeader > comes to mind, where the header values are defined as constants in the > API and an IllegalArgumentException is thrown if any other value is > passed - should we allow any non-null String values for the priority? > Or to take your example of q-value above - should we just allow any > non-null Float and let the parser enforce the 0-1 range? I think I understand the point about checking for null. I think, if you are dead set on adopting the set method as a way of constructing headers, one should validate arguments via the parser and throw ParseException for anything other than null arguments. On the other hand, I propose something entirely different for constructing headers (above). > > > >> >> >> >> > >> > >> > (If it is considered acceptable to have a "null" subType then we >> > should make it optional) >> > >> >> >> >> >> >> I don't quite follow the argument that lazy parsing >> >> "necessitates throwing a parse exception for all get methods". >> >> Here is what I had envisioned: >> >> >> >> >> >> 1 When a message comes in it will be separated into headers based >> >> on type. >> >> 2 The header would be returned with no field initialized except >> >> the text corresponding to the message. (this would necessitate >> >> examining the first few bytes of the message to determine the >> >> header type but the rest remains unparsed.) You can also stow >> >> away the type information in the Header that is returned as well >> >> to know which parser rule to invoke later. >> >> 3. Later, when the application wants to parse the header, it has >> >> the string corresponding to the message and can hand it off to >> >> the parser, which can then fill in the appropriate fields >> >> corresponding to the header. >> >> 4. Subsequently, the application can access the fields just as an >> >> eager parser based application would do. >> >> >> >> ( Where am I missing the boat with this? ) >> > >> > An application has no idea whether an implementation is using lazy >> > or eager parsing - it is simply passed a header object - and then >> > if it is interested in a particular field it calls the appropriate >> > get method (which would internally invoke the parser in a lazy >> > parsing implementation). So the application is completely oblivious >> > to whether or not this "optimisation" is used by the >> > implementation. >> >> >> Ah! ( Why is this hiding of the implementation so important? ) Can >> this be handled in the following fashion by an implementation: >> >> 1. The implementation keeps a flag in the class that implements the >> interface whether the parsing has been done or not (i.e. boolean >> parsingDone flag). >> >> 2. The Implementation keeps the entire string corresponding to the >> header in the object. So the parser has to peek into the message >> header to know what type the message is as soon as it has the >> header string and then grabs the string and stores it away for lazy >> parsing. >> >> >> 3. The get Method checks if the flag has been set, calls the parser >> to do the parse if the flag has not been set and then returns a >> parseException if the parse fails. This can be done transparently to >> the caller. > > This is exactly what I would expect a lazy-parsing implementation to > do - the fact that lazy-parsing is hidden from the application (except > that the application must catch a JainSipParseException on the get > methods to allow for the possibility that an implementation uses > lazy-parsing - so technically the application will know that an > implementation uses lazy-parsing if this exception is thrown by a get > method - but I think the two cases are handled nicely by the addition > of the exception) >> >> >> >> >> >> >> > >> > >> > If the field is optional and does not exist in the header a >> > ParameterNotSetException will be thrown by the implementation. >> >> A suggestion (shoot it down if it does not jive): >> >> 1. All fields are represented by objects (not simple types like int, >> use Integer instead). > > I buy this part - then the IllegalArgumentException is only ever > thrown if an object parameter is null, and the JainSipParseException > is thrown for all other problems with the argument. OK this jives and is easily defined. > > >> >> 2. If the field is not set just return null > > See above for null discussion, > >> >> >> >> >> > If the field is mandatory and does not exist, a >> > JainSipParseException will be thrown (header is malformed). If any >> > header field is malformed a JainSipParseException is thrown. If a >> > JainSipParseException is thrown, this indicates that the >> > application must use the header's getValue method to get a string >> > representation of the header value and do what it can with that. >> >> >> Why the headers getValue ? Why is the string not part of the >> Exception? > > Sure - we can say that the JainSipParseException's message must be the > string value of the header. OK Glad you buy that one. > > > >> >> >> >> > >> > >> >> >> >> >> >> It appears that what is being attempted here (please correct me >> >> if I am wrong) is to use exceptions as a mechanism to catch >> >> un-initialized fields so the parser can be invoked in the >> >> exception handler perhaps. This leads to a lot of overhead in >> >> clunky code. I think it is a mistake to throw exceptions on every >> >> get to try to protect the application from inadvertently >> >> accessing fields that have not been initialized. Why not just >> >> assume that the application must be smart enough to parse the >> >> header text before accessing fields and not try to provide a >> >> complex mechanism as above? >> > >> > >> > We are using ParameterNotSetException for the case of an optional >> > header not existing, and a JainSipParseException for the case of a >> > malformed header being received from the network. >> > >> > If we assume the application is smart enough to do all header value >> > parsing, we reduce a header to just being two strings - the type >> > and value, which puts the burden of parsing on an application - >> > this work can be done by the underlying implementation - doesn't it >> > make more sense for an application to catch an exception than have >> > to parse all header value strings (especially since this >> > functionality already exists in the underlying stack) >> >> >> No that is not what I had intended. Parser functionality exists in >> the stack but has to be called explicitly by the implementation. Too >> much hiding of the implementation from the application has its own >> set of disadvantages (IMHO). > > I wanted parser fuctionality to be invoked implicitly by an > application - from the API perspective it is an implementation detail > - so the application should not be aware of how or when the underlying > parser is invoked - it should just know that it is there in some form, > and that if it tries to get or set a value that the implementation > doesn't like it will get a JainSipParseException thrown back at it. > This is important if we want to maintain the three core values of JAIN > - portability, portability and portabilty ;) The point about portability is a good one. Of course the important thing about portability is to be able to maintain the same semantics of exceptions as well. For an eager parser, there is no possibility of throwing a parse exception on a get (i.e. parse exception can never occur on a getXXX) so there will be some curious code in a getXXX implementation for an eager parser that has to throw an exception even when it does not need to (just to keep the compiler happy). Second, the application has to be willing to catch such an exception to be able to function both with a lazy and an eager implementation in a transparent fashion and it may do different things when the implementation is lazy, which exposes the underlying implementation anyway as you have noted. Explicit control by the application may give the application finer grained control and eliminate some awkward exception handling that is not meaningful for an eager parser . This way, you can also have mixed mode parsing, allowing the application to decide what headers it wants to handle in a lazy fashion and which ones it wants to handle in an eager fashion. Another suggestion ( may be a bit radical) - would it make sense to have extension interfaces (with enhanced getXXX interfaces) that are only implemented by lazy parsers and make lazy parsing optional (so only highly performance sensitive apps will avail themselves of such interfaces whereas most applications will use the eager parser interfaces for getXXX). ( May or may not make sense, I thought I would mention it as it occured to me. ) Anyway, there is more ways than one to skin a cat. Just keep everything as simple as possible but no simpler. I am sure you are eager to bring this to closure so I will not belabor the point about eager parsing versus lazy parsing although, as a final point I would just like to state that portability can be handled whether or not the parse is explicitly or implicitly lazy. Enough said on this point. Regards, Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------E5356573E9C4502DE8749499 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Chris,

Thanks for the prompt response. Not to drag this on for ever, but I have a few more suggestions  in followup to your comments/clarifications  (in blue below). As  you are in Ireland, your missiles cannot reach me so I can be bold :)
 
 

Regards

Ranga.
 

A design issue not discussed below:

Whenever there is more than one header to be returned (via  headers for example), you return an array.  An array is easy to walk through. However,  I would think it more useful to return a collection of some sort that supports additional methods such as checking if an address exists in the list of headers returned etc. That might be of some use to an implementation.  If you define the returned type as an array of headers, there is no way to extend the class to support additional functionality.  May I suggest adding a collection class interface for collections of SIP Headers (and that can be specialized by implementations to support additional query methods etc.), say something like SIPHeaderList
 

Chris Harris wrote:

Ranga,

My comments are in red...

Chris
 

"M. Ranganathan" wrote:

Chris,

Thanks for the prompt response.  Hope you had a great Thanksgiving.

I wish there was such a thing as Thanksgiving in Ireland :(
 

My followup is below. ( in blue)

Regards

Ranga.

Chris Harris wrote:

Ranga,

See comments below.

Regards,
Chris

"M. Ranganathan" wrote:

 
Chris, Erik,

While we are on the subject of Exceptions, why do null arguments throw runtime exceptions when you do a get on them? For example, in the Accept interface, getContentSubtype throws a IllegalArgumentException if  is null. IMHO, I think it is valid to have a null subtype so why not just return null rather than throw exception here?

By a "doing a get on a null argument" here I assume you mean attempting to get a non-existent optional field? If you do this a checked ParameterNotSetException is thrown, not a runtime exception.


Yes. Thats what I had meant.  The word "argument" should have been "field".   Why do you need a  ParameterNotSet exception in this case?  Are you trying to handle the case of basic types like integers, floats and so on ? For objects, null is synonymous with not set isnt it?

We discussed this matter in depth at the last JAIN SIP meeting in October, and we came to the conclusion that getting and setting null values is not a good idea for several reasons e.g. it is easier to debug a ParameterNotSetException than searching for the source of a later NullPointerException, and it forces the application to allow for the fact that there is a reasonable chance that a particular field does not exist. [Of course, if we did allow the use of null, we could cut down on the number of methods and drop the ParameterNotSetException - but  is it really worth sacrificing clarity and robustness for the sake of cutting down on API size?]


Well, I guess that is a judgement call.  With this design, you may have code that is cluttered with a lot of exception handlers and the API is quite big.  Checking for null is fairly standard  (am I giving my age away ? :)  and I can see at least a few places in the base JAVA API where null is returned to denote empty  and anyway, the app has a good old stack trace to rely on to see the source of the exception when null pointers are encountered.   Guarding an application from null pointer exception is pretty hard anyway so why complicate the API to handle this one case?  ( For collections of SIPHeaders, you can check for empty collection and you will not have this problem. )
 
 

 
 
 

There are two approaches to handling optional header parts. One approach is to allow the passing and returning of null objects from get and set methods (implicit "remove" and "has"), and the other is to explicitly add has and remove methods (and exceptions on the set and get methods). As for mandatory header parts - I think passing null to a set method should definitely throw an IllegalArgumentException.

I have the following questions about setXXX methods:

1.  Why do you restrict throwing IllegalArgumentException to only null arguments in some of the headers? Why are you not checking for proper formatting of the passed arguments (by giving it to the parser for example and running the appropriate  parser rule).

In general, an IllegalArgumentException is thrown if an argument to a set method fails basic validation (i.e. no implementation-specific parsing is used). Note that an application can ensure that this exception is not thrown by following the rules defined in the API . So if an argument is a String, I throw an IllegalArgumentException if the argument is null or zero-length.

Of course this is not sufficient validation and the string must be parsed to check for whitespaces, newlines etc, and different implementations will be more tolerant than others. This is why there is a checked JainSipParseException - an application cannot tell in advance if a particular implementation will accept a certain value, so it must catch this exception.

I am proposing that this exception should also be thrown by get methods (for all fields), because if an implementation uses lazy parsing, then there is no guarantee that the header value will parse correctly upon the invocation of the get method, and again this is implementation-dependent.

 

2.  A more general question - why do you have set methods at all in the interfaces?  The class that implements the interface can have set methods but the interface itself does not need to have them.

I have set methods in the interfaces because the objects will not only be coming up from the implementation - an application needs to be able to create and send requests, and this means being able to set the values.
Ah! My understanding was correct then.

OK. Perhaps this would be too much of a change for you to consider but let me make a suggestion anyway ....

I think formatting headers should be considered under a different set of API.  Here is what I am suggesting

1. Get rid of the setXXX interfaces (the parser will have direct access to the classes and does not need them and it will cut down the size of the API).

2. Have a  SIPMessageFormatter interface who'se sole job it is to format output messages.  This can have methods to format the different outgoing messages and will throw parse exceptions if the strings that it gets are incorrect. The MessageFormatter interface takes as parameter values only Strings.

Concretely,  for example:

public interface SIPMessageFormatter {
        public String createFromMessage( String from ,  String tag) throws SIPParseException;

    .....................

}

It would be slower for an implementation to extract the same information out of a structure and hand it to a parser for validation (IMHO). A "loose implementation" may not want to be bothered with validation at all and leave it to the reciever to reject the mesage, thereby making the implementation faster or it may do very cursory checking.
 
 
 
 
 

 
 Moreover, the parser has the job of setting up stuff in the returned object. It has a set of BNF rules to decide on the correctness of the arguments and it does not need for the class to re-implement the check. For example, I think it ought to be the parser's job to check if the q value is between 0 and 1.   (Is the purpose of the set method to allow for the application to do header formatting?)
I absolutely agree that the parser should perform validation (hence the JainSipParseException) - but as I mentioned above there are certain basic criteria that must be met by all implementations and applications - I am using the IllegalArgumentException to cover these. Perhaps certain cases go too far in this validation - perhaps the IllegalArgumentException could be thrown only if a null argument is passed and all other validation is left up to the implementation's parser? (although a problem with certain cases such as PriorityHeader comes to mind, where the header values are defined as constants in the API and an IllegalArgumentException is thrown if any other value is passed - should we allow any non-null String values for the priority? Or to take your example of q-value above - should we just allow any non-null Float and let the parser enforce the 0-1 range?


I think I understand the point about checking for null.  I think, if you are dead set on adopting the set method as a way of constructing headers, one should validate arguments via the parser and throw ParseException for anything other than null arguments. On the other hand, I propose something entirely different for constructing headers (above).

 
 
 
 
 

(If it is considered acceptable to have a "null" subType then we should make it optional)

 

I don't quite follow the argument that lazy parsing  "necessitates throwing a parse exception for all get methods".   Here is what I had envisioned:
 

1 When a message comes in it will be separated into headers based on type.
2 The header would be returned with no field initialized except the text corresponding to the message. (this would necessitate examining the first few bytes of the message to determine the header type but the rest remains unparsed.) You can also stow away the type information in the Header that is returned as well to know which parser rule to invoke later.
3. Later, when the application wants to parse the header, it has the string corresponding to the message and can hand it off to the parser, which can then fill in the appropriate fields corresponding to the header.
4. Subsequently, the application can access the fields just as an eager parser based application would do.

( Where am I missing the boat with this? )

An application has no idea whether an implementation is using lazy or eager parsing - it is simply passed a header object - and then if it is interested in a particular field it calls the appropriate get method (which would internally invoke the parser in a lazy parsing implementation). So the application is completely oblivious to whether or not this "optimisation" is used by the implementation.


Ah! ( Why is this hiding  of the implementation so important? )  Can this be handled in the following fashion by an implementation:

1. The implementation keeps a flag in the  class that implements the interface whether the parsing has been done or not (i.e. boolean parsingDone flag).

2. The Implementation keeps the entire string corresponding to the header in the object. So the parser has to peek into the message header to know what type the message is as soon as it has the  header string and then grabs the string and stores it away for lazy parsing.
 

3. The get Method  checks if the flag has been set, calls the parser to do the parse if the flag has not been set and then returns a parseException if the parse fails. This can be done transparently to the caller.

This is exactly what I would expect a lazy-parsing implementation to do - the fact that lazy-parsing is hidden from the application (except that the application must catch a JainSipParseException on the get methods to allow for the possibility that an implementation uses lazy-parsing - so technically the application will know that an implementation uses lazy-parsing if this exception is thrown by a get method - but I think the two cases are handled nicely by the addition of the exception)
 
 
 
 
 
 

If the field is optional and does not exist in the header a ParameterNotSetException will be thrown by the implementation.

A suggestion (shoot it down if it does not jive):

1. All fields are represented by objects (not simple types like int, use Integer instead).

I buy this part - then the IllegalArgumentException is only ever thrown if an object parameter is null, and the JainSipParseException is thrown for all other problems with the argument.


OK this jives and is easily defined.

 
 
2. If the field is not set just return null
See above for null discussion,
 
 
 
If the field is mandatory and does not exist, a JainSipParseException will be thrown (header is malformed). If any header field is malformed a JainSipParseException is thrown. If a JainSipParseException is thrown, this indicates that the application must use the header's getValue method to get a string representation of the header value and do what it can with that.


Why the headers getValue ? Why is the string not part of the Exception?

Sure - we can say that the JainSipParseException's message must be the string value of the header.


OK Glad you buy that one.
 

 
 
 
 
 
 

It appears that what is being attempted here (please correct me if I am wrong) is to use exceptions as a mechanism to catch un-initialized fields so the parser can be invoked in the exception handler perhaps. This leads to a lot of overhead in clunky code. I think it is a mistake to throw exceptions on every get to try to protect the application from inadvertently accessing fields that have not been initialized.  Why not just assume that the application must be smart enough to parse the header text before accessing fields and not try to provide a complex mechanism as above?


We are using ParameterNotSetException for the case of an optional header not existing, and a JainSipParseException for the case of a malformed header being received from the network.

If we assume the application is smart enough to do all header value parsing, we reduce a header to just being two strings - the type and value, which puts the burden of parsing on an application - this work can be done by the underlying implementation - doesn't it make more sense for an application to catch an exception than have to parse all header value strings (especially since this functionality already exists in the underlying stack)


No that is not what I had intended. Parser functionality exists in the stack but has to be called explicitly by the implementation. Too much hiding of the implementation from the application has its own set of disadvantages (IMHO).

I wanted parser fuctionality to be invoked implicitly by an application - from the API perspective it is an implementation detail - so the application should not be aware of how or when the underlying parser is invoked - it should just know that it is there in some form, and that if it tries to get or set a value that the implementation doesn't like it will get a JainSipParseException thrown back at it. This is important if we want to maintain the three core values of JAIN - portability, portability and portabilty ;)


The point about portability is a good one. Of course the important thing about portability is to be able to maintain the same semantics of exceptions as well.  For an eager parser,  there is no possibility of throwing a parse  exception  on a get (i.e. parse exception can never occur on a getXXX) so there will be some curious code in a getXXX  implementation  for an eager parser that has to throw an exception even when it does not need to (just to keep the compiler happy).   Second,  the application has to be willing to catch such an exception to be able to function both with a lazy and an eager implementation in a transparent fashion and it may do different things when the implementation is lazy, which exposes the underlying implementation anyway as you have noted.  

Explicit control by the application may give the application finer grained control and eliminate some awkward exception handling that is  not meaningful for an eager parser .  This way, you can also have mixed mode parsing, allowing the application to decide what headers it wants to handle in a lazy fashion and which ones it wants to handle in an eager fashion.

Another suggestion ( may be a bit radical) - would it make sense to have extension interfaces (with enhanced getXXX  interfaces)  that are only implemented by lazy parsers and make lazy parsing optional (so only highly performance sensitive apps will  avail themselves of such interfaces whereas most applications will use the eager parser interfaces for getXXX).  ( May or may not make sense, I thought I would mention it as it occured to me.  )

Anyway,  there is more ways than one to skin a cat. Just keep everything as simple as possible but no simpler. I am sure you are eager to bring this to closure so I will not belabor the point about eager parsing versus lazy parsing  although, as a final point I would just like to state that portability can be handled whether or not the parse is explicitly or implicitly lazy. Enough said on this point.
 
 
 

Regards,

Ranga.
 
 
 
  

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------E5356573E9C4502DE8749499-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 16:37:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12933 for ; Mon, 27 Nov 2000 16:37:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0BACC44358; Mon, 27 Nov 2000 15:37:10 -0500 (EST) 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 5828A44336 for ; Mon, 27 Nov 2000 14:14:15 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA15135; Mon, 27 Nov 2000 12:14:08 -0800 (PST) Received: from cisco.com (vvs-lab-nat-171-69-180-242.cisco.com [171.69.180.242]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ABO03223 (AUTH sunithak); Mon, 27 Nov 2000 12:14:05 -0800 (PST) Message-ID: <3A22C08B.4A195BDA@cisco.com> From: Sunitha Kumar Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Voravit H." Cc: sip@lists.bell-labs.com Subject: Re: [SIP] About SDP References: Content-Type: multipart/alternative; boundary="------------D3810B77A5C2891EEEA06194" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 12:14:03 -0800 --------------D3810B77A5C2891EEEA06194 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Voravit: You can check out www.vovida.org for opensource SDP APIs. regards sunitha "Voravit H." wrote: > Dear all > > Is there any free SDP API for education purpose out there? > I am now trying to implement SIP but I stuck on SDP content. > > Mr. Voravit H. > > ------------------------------------------------------------------------ > Name: winmail.dat > winmail.dat Type: application/ms-tnef > Encoding: base64 -- Sunitha Kumar http://www.cisco.com --------------D3810B77A5C2891EEEA06194 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Voravit:

You can check out www.vovida.org for opensource SDP APIs.

regards
sunitha
 
 
 

"Voravit H." wrote:

Dear all

        Is there any free SDP API for education purpose out there?
        I am now trying to implement SIP but I stuck on SDP content.

Mr. Voravit H.

  ------------------------------------------------------------------------
                  Name: winmail.dat
   winmail.dat    Type: application/ms-tnef
              Encoding: base64

-- 
Sunitha Kumar
http://www.cisco.com
  --------------D3810B77A5C2891EEEA06194-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 16:39: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 QAA13654 for ; Mon, 27 Nov 2000 16:39:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7DA6C44380; Mon, 27 Nov 2000 15:37:24 -0500 (EST) 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 3D6AE4434E for ; Mon, 27 Nov 2000 15:36:20 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G4P00401D9NHW@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 27 Nov 2000 21:34:35 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G4P002B2D9MJK@firewall.mcit.com>; Mon, 27 Nov 2000 21:34:35 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0G4P00E01D9L0I@dgismtp02.wcomnet.com>; Mon, 27 Nov 2000 21:34:34 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G4P00D01D94W7@dgismtp02.wcomnet.com>; Mon, 27 Nov 2000 21:34:33 +0000 (GMT) Received: from hsinnreich ([166.44.60.205]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G4P00D2PD92K4@dgismtp02.wcomnet.com>; Mon, 27 Nov 2000 21:34:15 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] What SIP doesn't tell you how to do. In-reply-to: <20001127162931.15402.qmail@web11006.mail.yahoo.com> To: Brian S , 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=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 27 Nov 2000 15:34:24 -0600 Content-Transfer-Encoding: 7bit We should all thank Jonathan for answering countless questions on this list - acting as a volunteer help desk for everybody! Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Brian S Sent: Monday, November 27, 2000 10:30 AM To: sip@lists.bell-labs.com Subject: [SIP] What SIP doesn't tell you how to do. Apparently SIP doesn't tell you how to do any of the following as well: 1. Be professional. 2. Show others common courtesy. 3. Switch to decaf. BTW- He never asked how to do anything, just if it could be done. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, November 22, 2000 10:59 AM To: 'Sanjiv Deshpande'; sip@lists.bell-labs.com Subject: RE: [SIP] multiple location SIP is just a protocol. Thats it. Its a tool. If you want device A to call device B, it tells you how to do that. Like all tools, you can use them in many different ways. When you buy a hammer in Home Depot, does it tell you whether to use your left hand or right? How many fingers to grip with it? The size of the nails to use with it? Of course not. However, for some reason that I cannot fathom, many people seem to believe the opposite is true for protocols; that is, protocols need to insist on how syntax and semantics AND how they are applied to solve real world problems. This approach just results in systems that are useful to no one. Would you buy a hammer that said "for nails of length 1 inch only?" I doubt it. So, to be specific, SIP doesn't tell you how to do any of the following: 1. the color of the phones that use SIP 2. the GUI for SIP calls 3. how you build a network of proxy servers 4. whether a phone can make calls while its in a call 5. qualifications for human beings to make use of SIP softphones (i.e., IQ levels, height, or what have you). 6. how many simultaneous calls the device can be in Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Sanjiv Deshpande [mailto:sdeshpan@telcordia.com] > Sent: Wednesday, November 22, 2000 11:36 AM > To: sip@lists.bell-labs.com > Subject: [SIP] multiple location > > > > > > > Q: > INVITE Sent by UAC got forked and reached two UAS1 and UAS2 , > the UAC decided > to talk to UAS1. Is it possible that UAS2 (Assuming it is a > client also) can > make a call to someone else. > > > What I wanted to know is, A user can be contacted at multiple > location if one of > the location answers a CALL is it possible for somebody else > on behalf of that > user make CALLS or receive CALLS.... > > > Thanks > Sanjiv. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 20:34:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16385 for ; Mon, 27 Nov 2000 20:34:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 76ADD4434C; Mon, 27 Nov 2000 19:34:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj_ntserver3.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id 3425D44336 for ; Mon, 27 Nov 2000 19:33:26 -0500 (EST) Received: by sj_ntserver3.sj.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 17:33:18 -0800 Message-ID: From: "Emami-Nouri, Mohsen" 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] 305 response, what for! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 17:33:18 -0800 Hi dear all, I was trying to figure out what the 305 response gives additional info. to the requester, what the 301 or 302 already does not. RFC explains that 305 means the requested resource should be accessed through a proxy, can not I achieve the same by using 301 or 302? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 21:12:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25083 for ; Mon, 27 Nov 2000 21:12:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23C714433F; Mon, 27 Nov 2000 20:12:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 6B09844336 for ; Mon, 27 Nov 2000 20:10:54 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 27 Nov 2000 20:10:26 -0600 (CST) From: Billy Biggs To: "Emami-Nouri, Mohsen" Cc: SIP List Subject: Re: [SIP] 305 response, what for! Message-ID: <20001127201026.A26167@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from memami@nuera.com on Mon, Nov 27, 2000 at 05:33:18PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 20:10:26 -0600 Emami-Nouri, Mohsen (memami@nuera.com): > I was trying to figure out what the 305 response gives additional > info. to the requester, what the 301 or 302 already does not. RFC > explains that 305 means the requested resource should be accessed > through a proxy, can not I achieve the same by using 301 or 302? The wording implies that if you get a 305 you should send only that specific request through the proxy. Future requests within the call-leg should instead be directed at the old Contact address. I have doubts about mid-call redirects actually working at all, and I suspect that most implementations handle all 3xx responses identically, except maybe updating numbers when a 301 is received. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 22:04:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11257 for ; Mon, 27 Nov 2000 22:04:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 961F54435E; Mon, 27 Nov 2000 21:04:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 410C044336 for ; Mon, 27 Nov 2000 21:03:43 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 19:03:26 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Billy Biggs'" , Sean Olson Cc: Jonathan Rosenberg , Jo Hornsby , sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 27 Nov 2000 19:03:18 -0800 Hi guys, This whole non-SIP Route concept is scaring me . I whole hearted agree that when Route is used, the routing relationship is no longer just to the original destination but rather to the network location of the next Route'd proxy. [For this reason I am having misgivings about how worthwhile Jonathan's invariant that the Request-URI in some form represents the final UA is. If it just represents the direction ok I can live with that.] Take the tel case: you are not interested in routing to the tel: of the final destintion but rather in routing to the next proxy that wanted to remain in the path - through a globally udp-reachable address. For instance, UAC->P1->P2->P3->P4->UAS. If P3 Record-Routes with a some URL scheme scheme only known by adacent proxyies P2 and P4 then the call will fail because either the UAC or P1 must also be able to route to P3 based on the Route. So to patch that problem a raddr parameter is suggested - that all UA's and proxies must understand. However, the raddr must still specify a globally udp-reachable address for things to work (otherwise you run into the same problem). So what's the point? Just KISS and stick with SIP URL's. I think the simpler something is, the more likely it will be to work across everyone's SIP devices - and this is somethign you want to work. I would make the same argument for non-SIP Contacts (used for routing SIP calls not for providing alias/alternate route possibilities). IMO Request-URI's are different due to that fact that the Request-URI can be translated as it traverses a network - so you only have to know whether or not an adjacent proxy/UA supports a certain (non-SIP) URL scheme. This is NOT TRUE after the initial INVITE and you also no longer want to do network-independent routing. As an aside, we were discussing earlier that about route parameters and angle brackets. A couple of peopel agreed that for Record-Route: ;rr-param A UA or proxy does not need to include rr-param's when buidling the Request-URI (ie, the Record-Route header parameters). If you want parameters to be passed into the Request-URI, they should go _inside_ the angle brackets(ie, Record-Route Request-URI parameters). This follows standard URL rules and is intuitive given that the Request-URI cannot contain angle brackets. I look forward to hearing your point of view on this. Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Tuesday, November 28, 2000 1:29 AM > To: Sean Olson > Cc: Jonathan Rosenberg; Jo Hornsby; hgs@cs.columbia.edu; > sip@lists.bell-labs.com > Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) > > > Sean Olson (sean.olson@ericsson.com): > > >> Sorry, let me be more specific. Say I use a non-SIP URI > in the RR > >> (or Contact) of: > >> > >> ;raddr=udp/22.33.44.55:5060 > >> > >> My only choice for request-URI is "tel:911", but this does not > >> convey the destination of the request. Since you now can't route > >> based on request-URI, you can't use an outbound proxy, stuff breaks > >> in general. > > > > Why doesn't the outbound proxy RR? > > It does, but what if you call me directly and not through > my outbound > proxy? The INVITE transaction completes without my outbound > proxy being > placed in the Route. When I send a BYE or whatever, it will go to the > outbound proxy, and now your URI loses its significance. > > That's very brittle. > > >> 2. Should we standardize an raddr RR parameter and allow this to > >> be used for SIP URIs? > >> > >> I say no. In general this technique breaks with outbound > >> proxies or transparent proxies. If necessary, this could be > >> standardized outside of the SIP spec. > > > > Standardizing this as an extension doesn't really help. I'm curious > > why transparent proxies would be in the signalling path. Outbound > > proxies should RR (am I missing something here?) > > Transparent proxies are useful when you want to divert SIP requests > going out to the internet to go to a special firewall proxy. This is > common with HTTP. > > SIP and HTTP are elegant in their proxy-awareness. Messages can be > forwarded between proxies without information loss. However, with an > raddr or whatever, now the IP layer has significance to the meaning of > the message, which breaks the model. > > >> [...] but a client should know to convert a tel URI to a SIP URI > >> like phonenumber@gateway. I thought that was the point of them, > >> not to use them as a Request-URI. > > > > In this specific case, it may or may not be possible for the UAC to > > translate the tel: URI into a SIP URI. (How does the client > know which > > "domain" owns a specific number?) This is where an outbound > proxy may > > play a role. In any case, it may be useful in certain cases to use a > > Request-URI which is not directly routable. A proxy downstream can > > translate this into a Request-URI which is routable. [...] > > But now the client and the outbound proxy are together acting as a > single logical client. This technique, translating a tel: URI into a > SIP URI, can only be done at the edges, and does not work > unless you are > sure you are not going to hit some transparent proxy in the middle. > > My point is that URI schemes other than SIP are useful for internal > purposes. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 23:15:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28536 for ; Mon, 27 Nov 2000 23:15:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 59FF844353; Mon, 27 Nov 2000 22:15:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (uzura.cisco.com [161.44.3.77]) by lists.bell-labs.com (Postfix) with ESMTP id 2AFDC44336 for ; Mon, 27 Nov 2000 22:14:35 -0500 (EST) Received: from cisco.com (akher-dsl3.cisco.com [10.83.24.220]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA27200 for ; Mon, 27 Nov 2000 23:13:30 -0500 (EST) Message-ID: <3A2331CC.E9F91299@cisco.com> From: Ameet Kher Reply-To: akher@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Manyfolks draft 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: Mon, 27 Nov 2000 23:17:16 -0500 Content-Transfer-Encoding: 7bit Hi All, Need a clarification on the latest version of Manyfolks draft. For the case where a UAS receives an Invite with confirm tag , the UAS is expected to send out a Comet to the originator if it has the ability to do so. What should happen if after receiving an Invite with confirm tag the call is negotiated to a Best effort call and proceeds as Best effort. No reservations are done. The UAS has the ability to send a Comet. Question: Should a Comet be sent out by the UAS in this case ? Thanks Ameet _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Nov 27 23:46:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08214 for ; Mon, 27 Nov 2000 23:46:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C890C4435F; Mon, 27 Nov 2000 22:46:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id D1B4344336 for ; Mon, 27 Nov 2000 22:45:56 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 27 Nov 2000 22:45:25 -0600 (CST) From: Billy Biggs To: "Fairlie-Cuninghame, Robert" Cc: Sean Olson , Jonathan Rosenberg , Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) Message-ID: <20001127224524.A26210@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from rfairlie@nuera.com on Mon, Nov 27, 2000 at 07:03:18PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 22:45:25 -0600 Some brief comments: > Take the tel case: you are not interested in routing to the tel: of > the final destintion but rather in routing to the next proxy that > wanted to remain in the path - through a globally udp-reachable > address. For instance, UAC->P1->P2->P3->P4->UAS. If P3 Record-Routes > with a some URL scheme scheme only known by adacent proxyies P2 and P4 > then the call will fail because either the UAC or P1 must also be able > to route to P3 based on the Route. If P2 and P4 Record-Route then this isn't a problem. Allowing unknown URI schemes in the RR/Contact/ReqURI is cheap. However, they only work in a strictly engineered private network. > IMO Request-URI's are different due to that fact that the Request-URI > can be translated as it traverses a network - so you only have to know > whether or not an adjacent proxy/UA supports a certain (non-SIP) URL > scheme. This is NOT TRUE after the initial INVITE and you also no > longer want to do network-independent routing. There might be a transparent SIP proxy between you and this destination which will snarf the message, at which point you lose the ability to route based on request-URI. This is unacceptable. > As an aside, we were discussing earlier that about route parameters > and angle brackets. A couple of peopel agreed that for > > Record-Route: ;rr-param > > A UA or proxy does not need to include rr-param's when buidling the > Request-URI (ie, the Record-Route header parameters). If you want > parameters to be passed into the Request-URI, they should go _inside_ > the angle brackets(ie, Record-Route Request-URI parameters). This > follows standard URL rules and is intuitive given that the Request-URI > cannot contain angle brackets. You are correct that rr-params don't get copied into the request-URI. This is why placing routing information in rr-params is broken. This does not mean that rr-params are useless. They may be useful for extensions which require special behavior from the hop before. Note that parameters aren't standard across URI schemes. As such, we can't define, say, an "maddr" parameter and expect it to have significance in a tel URI. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 00:35: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 AAA20946 for ; Tue, 28 Nov 2000 00:35:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9905644359; Mon, 27 Nov 2000 23:35:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 33E0844336 for ; Mon, 27 Nov 2000 23:34:44 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 21:34:27 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Billy Biggs'" Cc: Sean Olson , Jonathan Rosenberg , Jo Hornsby , sip@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 27 Nov 2000 21:34:19 -0800 Hi Billy, > Some brief comments: Great. > > Take the tel case: you are not interested in routing to the tel: of > > the final destintion but rather in routing to the next proxy that > > wanted to remain in the path - through a globally udp-reachable > > address. For instance, UAC->P1->P2->P3->P4->UAS. If P3 Record-Routes > > with a some URL scheme scheme only known by adacent > proxyies P2 and P4 > > then the call will fail because either the UAC or P1 must > also be able > > to route to P3 based on the Route. > > If P2 and P4 Record-Route then this isn't a problem. > > Allowing unknown URI schemes in the RR/Contact/ReqURI is cheap. > However, they only work in a strictly engineered private network. I disagree that it is cheap. Sure its easy to just say "allow non-SIP URL's in Record-ROutes" but in my mind it adds a lot of extra brittleness and conceptual complexity that is not useful in anything _but_ strictly engineered private networks. If the network is a strictly engineered private network then surely the proxies can come up with a method of representing the required information in a SIP URL? > > > IMO Request-URI's are different due to that fact that the > Request-URI > > can be translated as it traverses a network - so you only > have to know > > whether or not an adjacent proxy/UA supports a certain (non-SIP) URL > > scheme. This is NOT TRUE after the initial INVITE and you also no > > longer want to do network-independent routing. > > There might be a transparent SIP proxy between you and this > destination which will snarf the message, at which point you lose the > ability to route based on request-URI. This is unacceptable. Ok, your right but I still purtain that this is different to placing a non-SIP URL in a Route header. With the Request-URI, once the request hits a proxy that converts the tel: URL to a sip: Request-URI then all further proxies don't need to understand tel URL's (which is a feasible requirement). If a proxy inserts a tel URL then all UA'a and proxies in the path must potentially understand how to route tel URL's - which is not feasible. As you argue, proxies could collude to "buffer" non-SIP Route URL's but will probably result in assymetic Routes and all sorts of other trouble for what gain? > > > As an aside, we were discussing earlier that about route parameters > > and angle brackets. A couple of peopel agreed that for > > > > Record-Route: ;rr-param > > > > > > You are correct that rr-params don't get copied into the > request-URI. > This is why placing routing information in rr-params is broken. We are not suggesting this. We are saying that implementation specific information (I think calling it routing information is confusing) can be placed into the URL parameters -not header parameters. > > This does not mean that rr-params are useless. They may be > useful for > extensions which require special behavior from the hop before. We agree on this. > > Note that parameters aren't standard across URI schemes. > As such, we > can't define, say, an "maddr" parameter and expect it to have > significance in a tel URI. EXACTLY!! You don't have this problem if you don't try to put non-SIP URL's in the Route header Why should any other SIP entity have to handle this information? Other entities only have to ensure that the message is routed to the proxy. Are saying that this private network has no concepts of routing via hostnames or addresses? Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 03: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 SMTP id DAA07211 for ; Tue, 28 Nov 2000 03:29:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85C6D4436F; Tue, 28 Nov 2000 02:29:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 8D77044336 for ; Tue, 28 Nov 2000 02:28:55 -0500 (EST) Received: from ms.uab.ericsson.se (ms-blue.uab.ericsson.se [134.138.224.109]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eAS8Sft03461; Tue, 28 Nov 2000 09:28:41 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.11.1/8.11.1/uab-3.3) with ESMTP id eAS8SfC10446; Tue, 28 Nov 2000 09:28:41 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id JAA23317; Tue, 28 Nov 2000 09:28:40 +0100 (MET) Message-ID: <3A236CB6.C8801F6F@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com Cc: "Fairlie-Cuninghame, Robert" Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus) References: <8vviou$vb1$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 28 Nov 2000 09:28:38 +0100 Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > Hi guys, > > So to patch that problem a raddr parameter is suggested - that all UA's and > proxies must understand. However, the raddr must still specify a globally > udp-reachable address for things to work (otherwise you run into the same > problem). So what's the point? Just KISS and stick with SIP URL's. I think > the simpler something is, the more likely it will be to work across > everyone's SIP devices - and this is somethign you want to work. > Well the reason for the raddr parameter is the same as the maddr parameter for SIP-URL. But having it as a RR parameter makes it more general and independent of type of URI. If you have a pool of machines building up a big SIP server you may want to make shure every new request for a certain call-leg ends up on a specific machine in the pool (where you have the states for this specific call-leg). This is what I understand maddr was for. But since maddr only exists for SIP-URL, how to do it for other types of URIs ? This is the reason why I suggested the raddr parameter. With the raddr parameter a server can specify which machine it wants further requests to be sent to regardless of what type of URI it has put into record-route. That was the idea anyway. If people are happy with that you only can have SIP-URLs in record-route then the raddr is not needed. Personally I see a risk that some new type of URI pops up in the future that SIP also needs to support in RR. -- 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 Nov 28 03:59: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 DAA20237 for ; Tue, 28 Nov 2000 03:59:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D35AC44381; Tue, 28 Nov 2000 02:59:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 148CC44336 for ; Tue, 28 Nov 2000 02:58:47 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 00:58:29 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Bertil Engelholm'" , SIP@lists.bell-labs.com Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus) 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, 28 Nov 2000 00:58:26 -0800 Hi Bertil, > > Well the reason for the raddr parameter is the same as the > maddr parameter for SIP-URL. But having it as a RR parameter > makes it more general and independent of type of URI. > If you have a pool of machines building up a big SIP server > you may want to make shure every new request for a certain > call-leg ends up on a specific machine in the pool (where > you have the states for this specific call-leg). This > is what I understand maddr was for. But since maddr only > exists for SIP-URL, how to do it for other types of URIs ? Are you suggesting something of the form: Record-Route: ;raddr=emergency.sd.com then the Request-URI will become simply tel:911 which sees potentially brittle to me. Something of the form Record-Route: where blah and blah2 represent implementation specific fields possibly encoding tel:911 [or better yet, something more useful to the proxy] will still always be routed to the proxy regardless of what happens in between. The field blah and blah2 only have significance to the proxy and hence don't need to be mandated/examined/interpreted/understood by anyone but the proxy. In this context, the SIP URL is essentially only describing the next hop address - much like the Via field. I haven't heard requests (yet) to put tel URL's into the Via fields becuase it is unneccessary - all you need is the address and port - all other information is significant only to the generating proxy and hence it can encode what it wants, right ? Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > This is the reason why I suggested the raddr parameter. > With the raddr parameter a server can specify which machine > it wants further requests to be sent to regardless of what > type of URI it has put into record-route. That was the idea > anyway. If people are happy with that you only can have > SIP-URLs in record-route then the raddr is not needed. > Personally I see a risk that some new type of URI pops > up in the future that SIP also needs to support in RR. > > -- > 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 Nov 28 04:15: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 EAA25560 for ; Tue, 28 Nov 2000 04:15:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E9F94438D; Tue, 28 Nov 2000 03:15:10 -0500 (EST) 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 CCE9044377 for ; Tue, 28 Nov 2000 03:14:46 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id eAS9EcB27356 for ; Tue, 28 Nov 2000 10:14:38 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Nov 28 10:14:38 2000 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 28 Nov 2000 10:14:37 +0100 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73E30@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ELN)" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Thanks Jonathan Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 28 Nov 2000 10:14:31 +0100 Henry is right. Jonathan is indeed answering a lot of questions. So Jonathan..thank you for your time and we are all looking forward for more "helpdesk" feedback. :-) Arnoud van Wijk -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] Sent: maandag 27 nov 2000 22:34 To: Brian S; sip@lists.bell-labs.com Subject: RE: [SIP] What SIP doesn't tell you how to do. We should all thank Jonathan for answering countless questions on this list - acting as a volunteer help desk for everybody! Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Brian S Sent: Monday, November 27, 2000 10:30 AM To: sip@lists.bell-labs.com Subject: [SIP] What SIP doesn't tell you how to do. Apparently SIP doesn't tell you how to do any of the following as well: 1. Be professional. 2. Show others common courtesy. 3. Switch to decaf. BTW- He never asked how to do anything, just if it could be done. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, November 22, 2000 10:59 AM To: 'Sanjiv Deshpande'; sip@lists.bell-labs.com Subject: RE: [SIP] multiple location SIP is just a protocol. Thats it. Its a tool. If you want device A to call device B, it tells you how to do that. Like all tools, you can use them in many different ways. When you buy a hammer in Home Depot, does it tell you whether to use your left hand or right? How many fingers to grip with it? The size of the nails to use with it? Of course not. However, for some reason that I cannot fathom, many people seem to believe the opposite is true for protocols; that is, protocols need to insist on how syntax and semantics AND how they are applied to solve real world problems. This approach just results in systems that are useful to no one. Would you buy a hammer that said "for nails of length 1 inch only?" I doubt it. So, to be specific, SIP doesn't tell you how to do any of the following: 1. the color of the phones that use SIP 2. the GUI for SIP calls 3. how you build a network of proxy servers 4. whether a phone can make calls while its in a call 5. qualifications for human beings to make use of SIP softphones (i.e., IQ levels, height, or what have you). 6. how many simultaneous calls the device can be in Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Sanjiv Deshpande [mailto:sdeshpan@telcordia.com] > Sent: Wednesday, November 22, 2000 11:36 AM > To: sip@lists.bell-labs.com > Subject: [SIP] multiple location > > > > > > > Q: > INVITE Sent by UAC got forked and reached two UAS1 and UAS2 , > the UAC decided > to talk to UAS1. Is it possible that UAS2 (Assuming it is a > client also) can > make a call to someone else. > > > What I wanted to know is, A user can be contacted at multiple > location if one of > the location answers a CALL is it possible for somebody else > on behalf of that > user make CALLS or receive CALLS.... > > > Thanks > Sanjiv. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 05: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 SMTP id FAA22975 for ; Tue, 28 Nov 2000 05:34:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF9C544339; Tue, 28 Nov 2000 04:34:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4925644336 for ; Tue, 28 Nov 2000 04:33:05 -0500 (EST) Received: from dynamicsoft.com (userab43.ie.uudial.com [212.120.133.143]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA12462; Tue, 28 Nov 2000 05:35:04 -0500 (EST) Message-ID: <3A23899A.CFD8299D@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mranga@nist.gov Cc: jainsip@sun.com, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP - Issues to be resolved References: <3A12B434.EE04C0E7@dynamicsoft.com> <3A130AB9.9A527F9E@nist.gov> <3A131F80.9060704@dynamicsoft.com> <3A16922C.EFDE9019@ericsson.com> <3A1A5BAC.A0975580@dynamicsoft.com> <3A1DC4BD.533272E6@nist.gov> <3A1E82FB.DA1FC1AC@dynamicsoft.com> <3A1E8DEE.EA2DACA0@nist.gov> <3A22781D.901412E0@dynamicsoft.com> <3A22C387.BF280383@nist.gov> Content-Type: multipart/alternative; boundary="------------AD771551279F78EBE6656E05" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 28 Nov 2000 10:31:54 +0000 --------------AD771551279F78EBE6656E05 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ranga, I think I'll go for green this time... Regards, Chris "M. Ranganathan" wrote: > Chris, > > Thanks for the prompt response. Not to drag this on for ever, but I > have a few more suggestions in followup to your > comments/clarifications (in blue below). As you are in Ireland, your > missiles cannot reach me so I can be bold :) > > > > Regards > > Ranga. > > > A design issue not discussed below: > > Whenever there is more than one header to be returned (via headers > for example), you return an array. An array is easy to walk through. > However, I would think it more useful to return a collection of some > sort that supports additional methods such as checking if an address > exists in the list of headers returned etc. That might be of some use > to an implementation. If you define the returned type as an array of > headers, there is no way to extend the class to support additional > functionality. May I suggest adding a collection class interface for > collections of SIP Headers (and that can be specialized by > implementations to support additional query methods etc.), say > something like SIPHeaderList I initially wanted to return a Vector, but was told that an array was preferable for API's. Besides, any addition of functionality would be purely for the implementor's benefit and would not be available (without using reflection anway) to the application. > > > > Chris Harris wrote: > >> Ranga, >> >> My comments are in red... >> >> Chris >> >> >> "M. Ranganathan" wrote: >> >> > Chris, >> > >> > Thanks for the prompt response. Hope you had a great Thanksgiving. >> >> I wish there was such a thing as Thanksgiving in Ireland :( >> >> > >> > >> > My followup is below. ( in blue) >> > >> > Regards >> > >> > Ranga. >> > >> > Chris Harris wrote: >> > >> >> Ranga, >> >> >> >> See comments below. >> >> >> >> Regards, >> >> Chris >> >> >> >> "M. Ranganathan" wrote: >> >> >> >> > >> >> > Chris, Erik, >> >> > >> >> > While we are on the subject of Exceptions, why do null >> >> > arguments throw runtime exceptions when you do a get on them? >> >> > For example, in the Accept interface, getContentSubtype throws >> >> > a IllegalArgumentException if is null. IMHO, I think it is >> >> > valid to have a null subtype so why not just return null rather >> >> > than throw exception here? >> >> >> >> By a "doing a get on a null argument" here I assume you mean >> >> attempting to get a non-existent optional field? If you do this a >> >> checked ParameterNotSetException is thrown, not a runtime >> >> exception. >> > >> > >> > Yes. Thats what I had meant. The word "argument" should have been >> > "field". Why do you need a ParameterNotSet exception in this >> > case? Are you trying to handle the case of basic types like >> > integers, floats and so on ? For objects, null is synonymous with >> > not set isnt it? >> >> We discussed this matter in depth at the last JAIN SIP meeting in >> October, and we came to the conclusion that getting and setting null >> values is not a good idea for several reasons e.g. it is easier to >> debug a ParameterNotSetException than searching for the source of a >> later NullPointerException, and it forces the application to allow >> for the fact that there is a reasonable chance that a particular >> field does not exist. [Of course, if we did allow the use of null, >> we could cut down on the number of methods and drop the >> ParameterNotSetException - but is it really worth sacrificing >> clarity and robustness for the sake of cutting down on API size?] > > > Well, I guess that is a judgement call. With this design, you may > have code that is cluttered with a lot of exception handlers and the > API is quite big. Checking for null is fairly standard (am I giving > my age away ? :) and I can see at least a few places in the base JAVA > API where null is returned to denote empty and anyway, the app has a > good old stack trace to rely on to see the source of the exception > when null pointers are encountered. Guarding an application from > null pointer exception is pretty hard anyway so why complicate the API > to handle this one case? ( For collections of SIPHeaders, you can > check for empty collection and you will not have this problem. ) > I guess it is a judgement call. I actually approached this topic at the meeting from your perspective (devil's advocate? :) ) There were a few who agreed (who admitted that their opinion was due to their C background!), but the majority preferred the explicit handling of the ParameterNotSetException and the use of has and remove methods to be on the safe side. I hear what you are saying about null being sprinkled about in the core Java APIs - but even Sun can make mistakes :) > > > >> >> >> > >> > >> >> >> >> >> >> There are two approaches to handling optional header parts. One >> >> approach is to allow the passing and returning of null objects >> >> from get and set methods (implicit "remove" and "has"), and the >> >> other is to explicitly add has and remove methods (and exceptions >> >> on the set and get methods). As for mandatory header parts - I >> >> think passing null to a set method should definitely throw an >> >> IllegalArgumentException. >> > >> > I have the following questions about setXXX methods: >> > >> > 1. Why do you restrict throwing IllegalArgumentException to only >> > null arguments in some of the headers? Why are you not checking for >> > proper formatting of the passed arguments (by giving it to the >> > parser for example and running the appropriate parser rule). >> >> In general, an IllegalArgumentException is thrown if an argument to >> a set method fails basic validation (i.e. no implementation-specific >> parsing is used). Note that an application can ensure that this >> exception is not thrown by following the rules defined in the API . >> So if an argument is a String, I throw an IllegalArgumentException >> if the argument is null or zero-length. >> >> Of course this is not sufficient validation and the string must be >> parsed to check for whitespaces, newlines etc, and different >> implementations will be more tolerant than others. This is why there >> is a checked JainSipParseException - an application cannot tell in >> advance if a particular implementation will accept a certain value, >> so it must catch this exception. >> >> I am proposing that this exception should also be thrown by get >> methods (for all fields), because if an implementation uses lazy >> parsing, then there is no guarantee that the header value will parse >> correctly upon the invocation of the get method, and again this is >> implementation-dependent. >> >> > >> > >> > 2. A more general question - why do you have set methods at all in >> > the interfaces? The class that implements the interface can have >> > set methods but the interface itself does not need to have them. >> >> I have set methods in the interfaces because the objects will not >> only be coming up from the implementation - an application needs to >> be able to create and send requests, and this means being able to >> set the values. > > Ah! My understanding was correct then. > > OK. Perhaps this would be too much of a change for you to consider but > let me make a suggestion anyway .... > > I think formatting headers should be considered under a different set > of API. Here is what I am suggesting > > 1. Get rid of the setXXX interfaces (the parser will have direct > access to the classes and does not need them and it will cut down the > size of the API). > > 2. Have a SIPMessageFormatter interface who'se sole job it is to > format output messages. This can have methods to format the different > outgoing messages and will throw parse exceptions if the strings that > it gets are incorrect. The MessageFormatter interface takes as > parameter values only Strings. > > Concretely, for example: > > public interface SIPMessageFormatter { > public String createFromMessage( String from , String tag) > throws SIPParseException; > > ..................... > > } > > It would be slower for an implementation to extract the same > information out of a structure and hand it to a parser for validation > (IMHO). A "loose implementation" may not want to be bothered with > validation at all and leave it to the reciever to reject the mesage, > thereby making the implementation faster or it may do very cursory > checking. > This is a major change at this stage (public review technically closes today) - I personally don't think it's very OO, but I would be interested to hear other people's opinons. > > > > > >> >> >> > Moreover, the parser has the job of setting up stuff in the >> > returned object. It has a set of BNF rules to decide on the >> > correctness of the arguments and it does not need for the class to >> > re-implement the check. For example, I think it ought to be the >> > parser's job to check if the q value is between 0 and 1. (Is the >> > purpose of the set method to allow for the application to do header >> > formatting?) >> >> I absolutely agree that the parser should perform validation (hence >> the JainSipParseException) - but as I mentioned above there are >> certain basic criteria that must be met by all implementations and >> applications - I am using the IllegalArgumentException to cover >> these. Perhaps certain cases go too far in this validation - perhaps >> the IllegalArgumentException could be thrown only if a null argument >> is passed and all other validation is left up to the >> implementation's parser? (although a problem with certain cases such >> as PriorityHeader comes to mind, where the header values are defined >> as constants in the API and an IllegalArgumentException is thrown if >> any other value is passed - should we allow any non-null String >> values for the priority? Or to take your example of q-value above - >> should we just allow any non-null Float and let the parser enforce >> the 0-1 range? > > > I think I understand the point about checking for null. I think, if > you are dead set on adopting the set method as a way of constructing > headers, one should validate arguments via the parser and throw > ParseException for anything other than null arguments. On the other > hand, I propose something entirely different for constructing headers > (above). > >> >> >> >> > >> > >> > >> >> >> >> >> >> (If it is considered acceptable to have a "null" subType then we >> >> should make it optional) >> >> >> >> > >> >> > >> >> > I don't quite follow the argument that lazy parsing >> >> > "necessitates throwing a parse exception for all get >> >> > methods". Here is what I had envisioned: >> >> > >> >> > >> >> > 1 When a message comes in it will be separated into headers >> >> > based on type. >> >> > 2 The header would be returned with no field initialized except >> >> > the text corresponding to the message. (this would necessitate >> >> > examining the first few bytes of the message to determine the >> >> > header type but the rest remains unparsed.) You can also stow >> >> > away the type information in the Header that is returned as >> >> > well to know which parser rule to invoke later. >> >> > 3. Later, when the application wants to parse the header, it >> >> > has the string corresponding to the message and can hand it off >> >> > to the parser, which can then fill in the appropriate fields >> >> > corresponding to the header. >> >> > 4. Subsequently, the application can access the fields just as >> >> > an eager parser based application would do. >> >> > >> >> > ( Where am I missing the boat with this? ) >> >> >> >> An application has no idea whether an implementation is using >> >> lazy or eager parsing - it is simply passed a header object - and >> >> then if it is interested in a particular field it calls the >> >> appropriate get method (which would internally invoke the parser >> >> in a lazy parsing implementation). So the application is >> >> completely oblivious to whether or not this "optimisation" is >> >> used by the implementation. >> > >> > >> > Ah! ( Why is this hiding of the implementation so important? ) >> > Can this be handled in the following fashion by an implementation: >> > >> > 1. The implementation keeps a flag in the class that implements >> > the interface whether the parsing has been done or not (i.e. >> > boolean parsingDone flag). >> > >> > 2. The Implementation keeps the entire string corresponding to the >> > header in the object. So the parser has to peek into the message >> > header to know what type the message is as soon as it has the >> > header string and then grabs the string and stores it away for lazy >> > parsing. >> > >> > >> > 3. The get Method checks if the flag has been set, calls the >> > parser to do the parse if the flag has not been set and then >> > returns a parseException if the parse fails. This can be done >> > transparently to the caller. >> >> This is exactly what I would expect a lazy-parsing implementation to >> do - the fact that lazy-parsing is hidden from the application >> (except that the application must catch a JainSipParseException on >> the get methods to allow for the possibility that an implementation >> uses lazy-parsing - so technically the application will know that an >> implementation uses lazy-parsing if this exception is thrown by a >> get method - but I think the two cases are handled nicely by the >> addition of the exception) > >> > >> > >> > >> > >> > >> > >> >> >> >> >> >> If the field is optional and does not exist in the header a >> >> ParameterNotSetException will be thrown by the implementation. >> > >> > A suggestion (shoot it down if it does not jive): >> > >> > 1. All fields are represented by objects (not simple types like >> > int, use Integer instead). >> >> I buy this part - then the IllegalArgumentException is only ever >> thrown if an object parameter is null, and the JainSipParseException >> is thrown for all other problems with the argument. > > > OK this jives and is easily defined. > >> >> >> > >> > 2. If the field is not set just return null >> >> See above for null discussion, >> >> > >> > >> > >> > >> >> If the field is mandatory and does not exist, a >> >> JainSipParseException will be thrown (header is malformed). If >> >> any header field is malformed a JainSipParseException is thrown. >> >> If a JainSipParseException is thrown, this indicates that the >> >> application must use the header's getValue method to get a string >> >> representation of the header value and do what it can with that. >> > >> > >> > Why the headers getValue ? Why is the string not part of the >> > Exception? >> >> Sure - we can say that the JainSipParseException's message must be >> the string value of the header. > > > OK Glad you buy that one. I was just wondering what the message of a JainSipParseException thrown from a set method should contain - the value passed in? Perhaps we should add a string field to the JainSipParseException (say unparsable) which can be whatever the parser was unable to parse? Then the message can be left for explanatory comments. > > > >> > >> >> >> > >> > >> > >> >> >> >> >> >> > >> >> > >> >> > It appears that what is being attempted here (please correct me >> >> > if I am wrong) is to use exceptions as a mechanism to catch >> >> > un-initialized fields so the parser can be invoked in the >> >> > exception handler perhaps. This leads to a lot of overhead in >> >> > clunky code. I think it is a mistake to throw exceptions on >> >> > every get to try to protect the application from inadvertently >> >> > accessing fields that have not been initialized. Why not just >> >> > assume that the application must be smart enough to parse the >> >> > header text before accessing fields and not try to provide a >> >> > complex mechanism as above? >> >> >> >> >> >> We are using ParameterNotSetException for the case of an optional >> >> header not existing, and a JainSipParseException for the case of >> >> a malformed header being received from the network. >> >> >> >> If we assume the application is smart enough to do all header >> >> value parsing, we reduce a header to just being two strings - the >> >> type and value, which puts the burden of parsing on an >> >> application - this work can be done by the underlying >> >> implementation - doesn't it make more sense for an application to >> >> catch an exception than have to parse all header value strings >> >> (especially since this functionality already exists in the >> >> underlying stack) >> > >> > >> > No that is not what I had intended. Parser functionality exists in >> > the stack but has to be called explicitly by the implementation. >> > Too much hiding of the implementation from the application has its >> > own set of disadvantages (IMHO). >> >> I wanted parser fuctionality to be invoked implicitly by an >> application - from the API perspective it is an implementation >> detail - so the application should not be aware of how or when the >> underlying parser is invoked - it should just know that it is there >> in some form, and that if it tries to get or set a value that the >> implementation doesn't like it will get a JainSipParseException >> thrown back at it. This is important if we want to maintain the >> three core values of JAIN - portability, portability and portabilty >> ;) > > > The point about portability is a good one. Of course the important > thing about portability is to be able to maintain the same semantics > of exceptions as well. For an eager parser, there is no possibility > of throwing a parse exception on a get (i.e. parse exception can > never occur on a getXXX) so there will be some curious code in a > getXXX implementation for an eager parser that has to throw an > exception even when it does not need to (just to keep the compiler > happy). Second, the application has to be willing to catch such an > exception to be able to function both with a lazy and an eager > implementation in a transparent fashion and it may do different things > when the implementation is lazy, which exposes the underlying > implementation anyway as you have noted. > > Explicit control by the application may give the application finer > grained control and eliminate some awkward exception handling that is > not meaningful for an eager parser . This way, you can also have > mixed mode parsing, allowing the application to decide what headers it > wants to handle in a lazy fashion and which ones it wants to handle in > an eager fashion. The application does not get to decide which method is used by an implementation - an implementation could be lazy, eager or, as you point out, a mixture of both. An application has to accomodate this fact to be portable. > > > Another suggestion ( may be a bit radical) - would it make sense to > have extension interfaces (with enhanced getXXX interfaces) that are > only implemented by lazy parsers and make lazy parsing optional (so > only highly performance sensitive apps will avail themselves of such > interfaces whereas most applications will use the eager parser > interfaces for getXXX). ( May or may not make sense, I thought I > would mention it as it occured to me. ) Again, the application does not choose - the implementator does. > > > Anyway, there is more ways than one to skin a cat. Just keep > everything as simple as possible but no simpler. I am sure you are > eager to bring this to closure so I will not belabor the point about > eager parsing versus lazy parsing although, as a final point I would > just like to state that portability can be handled whether or not the > parse is explicitly or implicitly lazy. Enough said on this point. Thanks for all your input Ranga! > > > > > > Regards, > > Ranga. > > > > > > -- > M.Ranganathan > NIST Advanced Networking Technologies Group, > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > Tel: 301 975 3664 Fax: 301 590 0932 > > --------------AD771551279F78EBE6656E05 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ranga,

I think I'll go for green this time...

Regards,
Chris
 

"M. Ranganathan" wrote:

Chris,

Thanks for the prompt response. Not to drag this on for ever, but I have a few more suggestions  in followup to your comments/clarifications  (in blue below). As  you are in Ireland, your missiles cannot reach me so I can be bold :)
 
 

Regards

Ranga.
 

A design issue not discussed below:

Whenever there is more than one header to be returned (via  headers for example), you return an array.  An array is easy to walk through. However,  I would think it more useful to return a collection of some sort that supports additional methods such as checking if an address exists in the list of headers returned etc. That might be of some use to an implementation.  If you define the returned type as an array of headers, there is no way to extend the class to support additional functionality.  May I suggest adding a collection class interface for collections of SIP Headers (and that can be specialized by implementations to support additional query methods etc.), say something like SIPHeaderList

I initially wanted to return a Vector, but was told that an array was preferable for API's. Besides, any addition of functionality would be purely for the implementor's benefit and would not be available (without using reflection anway) to the application.
 
 

Chris Harris wrote:

Ranga,

My comments are in red...

Chris
 

"M. Ranganathan" wrote:

Chris,

Thanks for the prompt response.  Hope you had a great Thanksgiving.

I wish there was such a thing as Thanksgiving in Ireland :(
 

My followup is below. ( in blue)

Regards

Ranga.

Chris Harris wrote:

Ranga,

See comments below.

Regards,
Chris

"M. Ranganathan" wrote:

 
Chris, Erik,

While we are on the subject of Exceptions, why do null arguments throw runtime exceptions when you do a get on them? For example, in the Accept interface, getContentSubtype throws a IllegalArgumentException if  is null. IMHO, I think it is valid to have a null subtype so why not just return null rather than throw exception here?

By a "doing a get on a null argument" here I assume you mean attempting to get a non-existent optional field? If you do this a checked ParameterNotSetException is thrown, not a runtime exception.


Yes. Thats what I had meant.  The word "argument" should have been "field".   Why do you need a  ParameterNotSet exception in this case?  Are you trying to handle the case of basic types like integers, floats and so on ? For objects, null is synonymous with not set isnt it?

We discussed this matter in depth at the last JAIN SIP meeting in October, and we came to the conclusion that getting and setting null values is not a good idea for several reasons e.g. it is easier to debug a ParameterNotSetException than searching for the source of a later NullPointerException, and it forces the application to allow for the fact that there is a reasonable chance that a particular field does not exist. [Of course, if we did allow the use of null, we could cut down on the number of methods and drop the ParameterNotSetException - but  is it really worth sacrificing clarity and robustness for the sake of cutting down on API size?]


Well, I guess that is a judgement call.  With this design, you may have code that is cluttered with a lot of exception handlers and the API is quite big.  Checking for null is fairly standard  (am I giving my age away ? :)  and I can see at least a few places in the base JAVA API where null is returned to denote empty  and anyway, the app has a good old stack trace to rely on to see the source of the exception when null pointers are encountered.   Guarding an application from null pointer exception is pretty hard anyway so why complicate the API to handle this one case?  ( For collections of SIPHeaders, you can check for empty collection and you will not have this problem. )
 

I guess it is a judgement call. I actually approached this topic at the meeting from your perspective (devil's advocate? :) ) There were a few who agreed (who admitted that their opinion was due to their C background!), but the majority preferred the explicit handling of the ParameterNotSetException and the use of has and remove methods to be on the safe side. I hear what you are saying about null being sprinkled about in the core Java APIs - but even Sun can make mistakes :)
 
 
 
 
 

There are two approaches to handling optional header parts. One approach is to allow the passing and returning of null objects from get and set methods (implicit "remove" and "has"), and the other is to explicitly add has and remove methods (and exceptions on the set and get methods). As for mandatory header parts - I think passing null to a set method should definitely throw an IllegalArgumentException.

I have the following questions about setXXX methods:

1.  Why do you restrict throwing IllegalArgumentException to only null arguments in some of the headers? Why are you not checking for proper formatting of the passed arguments (by giving it to the parser for example and running the appropriate  parser rule).

In general, an IllegalArgumentException is thrown if an argument to a set method fails basic validation (i.e. no implementation-specific parsing is used). Note that an application can ensure that this exception is not thrown by following the rules defined in the API . So if an argument is a String, I throw an IllegalArgumentException if the argument is null or zero-length.

Of course this is not sufficient validation and the string must be parsed to check for whitespaces, newlines etc, and different implementations will be more tolerant than others. This is why there is a checked JainSipParseException - an application cannot tell in advance if a particular implementation will accept a certain value, so it must catch this exception.

I am proposing that this exception should also be thrown by get methods (for all fields), because if an implementation uses lazy parsing, then there is no guarantee that the header value will parse correctly upon the invocation of the get method, and again this is implementation-dependent.

 

2.  A more general question - why do you have set methods at all in the interfaces?  The class that implements the interface can have set methods but the interface itself does not need to have them.

I have set methods in the interfaces because the objects will not only be coming up from the implementation - an application needs to be able to create and send requests, and this means being able to set the values.
Ah! My understanding was correct then.

OK. Perhaps this would be too much of a change for you to consider but let me make a suggestion anyway ....

I think formatting headers should be considered under a different set of API.  Here is what I am suggesting

1. Get rid of the setXXX interfaces (the parser will have direct access to the classes and does not need them and it will cut down the size of the API).

2. Have a  SIPMessageFormatter interface who'se sole job it is to format output messages.  This can have methods to format the different outgoing messages and will throw parse exceptions if the strings that it gets are incorrect. The MessageFormatter interface takes as parameter values only Strings.

Concretely,  for example:

public interface SIPMessageFormatter {
        public String createFromMessage( String from ,  String tag) throws SIPParseException;

    .....................

}

It would be slower for an implementation to extract the same information out of a structure and hand it to a parser for validation (IMHO). A "loose implementation" may not want to be bothered with validation at all and leave it to the reciever to reject the mesage, thereby making the implementation faster or it may do very cursory checking.
 

This is a major change at this stage (public review technically closes today)  - I personally don't think it's very OO, but I would be interested to hear other people's opinons. 
 
 
 
 
 
 Moreover, the parser has the job of setting up stuff in the returned object. It has a set of BNF rules to decide on the correctness of the arguments and it does not need for the class to re-implement the check. For example, I think it ought to be the parser's job to check if the q value is between 0 and 1.   (Is the purpose of the set method to allow for the application to do header formatting?)
I absolutely agree that the parser should perform validation (hence the JainSipParseException) - but as I mentioned above there are certain basic criteria that must be met by all implementations and applications - I am using the IllegalArgumentException to cover these. Perhaps certain cases go too far in this validation - perhaps the IllegalArgumentException could be thrown only if a null argument is passed and all other validation is left up to the implementation's parser? (although a problem with certain cases such as PriorityHeader comes to mind, where the header values are defined as constants in the API and an IllegalArgumentException is thrown if any other value is passed - should we allow any non-null String values for the priority? Or to take your example of q-value above - should we just allow any non-null Float and let the parser enforce the 0-1 range?


I think I understand the point about checking for null.  I think, if you are dead set on adopting the set method as a way of constructing headers, one should validate arguments via the parser and throw ParseException for anything other than null arguments. On the other hand, I propose something entirely different for constructing headers (above).

 
 
 
 
 

(If it is considered acceptable to have a "null" subType then we should make it optional)

 

I don't quite follow the argument that lazy parsing  "necessitates throwing a parse exception for all get methods".   Here is what I had envisioned:
 

1 When a message comes in it will be separated into headers based on type.
2 The header would be returned with no field initialized except the text corresponding to the message. (this would necessitate examining the first few bytes of the message to determine the header type but the rest remains unparsed.) You can also stow away the type information in the Header that is returned as well to know which parser rule to invoke later.
3. Later, when the application wants to parse the header, it has the string corresponding to the message and can hand it off to the parser, which can then fill in the appropriate fields corresponding to the header.
4. Subsequently, the application can access the fields just as an eager parser based application would do.

( Where am I missing the boat with this? )

An application has no idea whether an implementation is using lazy or eager parsing - it is simply passed a header object - and then if it is interested in a particular field it calls the appropriate get method (which would internally invoke the parser in a lazy parsing implementation). So the application is completely oblivious to whether or not this "optimisation" is used by the implementation.


Ah! ( Why is this hiding  of the implementation so important? )  Can this be handled in the following fashion by an implementation:

1. The implementation keeps a flag in the  class that implements the interface whether the parsing has been done or not (i.e. boolean parsingDone flag).

2. The Implementation keeps the entire string corresponding to the header in the object. So the parser has to peek into the message header to know what type the message is as soon as it has the  header string and then grabs the string and stores it away for lazy parsing.
 

3. The get Method  checks if the flag has been set, calls the parser to do the parse if the flag has not been set and then returns a parseException if the parse fails. This can be done transparently to the caller.

This is exactly what I would expect a lazy-parsing implementation to do - the fact that lazy-parsing is hidden from the application (except that the application must catch a JainSipParseException on the get methods to allow for the possibility that an implementation uses lazy-parsing - so technically the application will know that an implementation uses lazy-parsing if this exception is thrown by a get method - but I think the two cases are handled nicely by the addition of the exception)
 
 
 
 
 
 

If the field is optional and does not exist in the header a ParameterNotSetException will be thrown by the implementation.

A suggestion (shoot it down if it does not jive):

1. All fields are represented by objects (not simple types like int, use Integer instead).

I buy this part - then the IllegalArgumentException is only ever thrown if an object parameter is null, and the JainSipParseException is thrown for all other problems with the argument.


OK this jives and is easily defined.

 
 
2. If the field is not set just return null
See above for null discussion,
 
 
 
If the field is mandatory and does not exist, a JainSipParseException will be thrown (header is malformed). If any header field is malformed a JainSipParseException is thrown. If a JainSipParseException is thrown, this indicates that the application must use the header's getValue method to get a string representation of the header value and do what it can with that.


Why the headers getValue ? Why is the string not part of the Exception?

Sure - we can say that the JainSipParseException's message must be the string value of the header.


OK Glad you buy that one.

I was just wondering what the message of a JainSipParseException thrown from a set method should contain - the value passed in? Perhaps we should add a string field to the JainSipParseException (say unparsable) which can be whatever the parser was unable to parse? Then the message can be left for explanatory comments.
 
 
 
 
 
 
 
 

It appears that what is being attempted here (please correct me if I am wrong) is to use exceptions as a mechanism to catch un-initialized fields so the parser can be invoked in the exception handler perhaps. This leads to a lot of overhead in clunky code. I think it is a mistake to throw exceptions on every get to try to protect the application from inadvertently accessing fields that have not been initialized.  Why not just assume that the application must be smart enough to parse the header text before accessing fields and not try to provide a complex mechanism as above?


We are using ParameterNotSetException for the case of an optional header not existing, and a JainSipParseException for the case of a malformed header being received from the network.

If we assume the application is smart enough to do all header value parsing, we reduce a header to just being two strings - the type and value, which puts the burden of parsing on an application - this work can be done by the underlying implementation - doesn't it make more sense for an application to catch an exception than have to parse all header value strings (especially since this functionality already exists in the underlying stack)


No that is not what I had intended. Parser functionality exists in the stack but has to be called explicitly by the implementation. Too much hiding of the implementation from the application has its own set of disadvantages (IMHO).

I wanted parser fuctionality to be invoked implicitly by an application - from the API perspective it is an implementation detail - so the application should not be aware of how or when the underlying parser is invoked - it should just know that it is there in some form, and that if it tries to get or set a value that the implementation doesn't like it will get a JainSipParseException thrown back at it. This is important if we want to maintain the three core values of JAIN - portability, portability and portabilty ;)


The point about portability is a good one. Of course the important thing about portability is to be able to maintain the same semantics of exceptions as well.  For an eager parser,  there is no possibility of throwing a parse  exception  on a get (i.e. parse exception can never occur on a getXXX) so there will be some curious code in a getXXX  implementation  for an eager parser that has to throw an exception even when it does not need to (just to keep the compiler happy).   Second,  the application has to be willing to catch such an exception to be able to function both with a lazy and an eager implementation in a transparent fashion and it may do different things when the implementation is lazy, which exposes the underlying implementation anyway as you have noted.

Explicit control by the application may give the application finer grained control and eliminate some awkward exception handling that is  not meaningful for an eager parser .  This way, you can also have mixed mode parsing, allowing the application to decide what headers it wants to handle in a lazy fashion and which ones it wants to handle in an eager fashion.

The application does not get to decide which method is used by an implementation - an implementation could be lazy, eager or, as you point out, a mixture of both. An application has to accomodate this fact to be portable.
 

Another suggestion ( may be a bit radical) - would it make sense to have extension interfaces (with enhanced getXXX  interfaces)  that are only implemented by lazy parsers and make lazy parsing optional (so only highly performance sensitive apps will  avail themselves of such interfaces whereas most applications will use the eager parser interfaces for getXXX).  ( May or may not make sense, I thought I would mention it as it occured to me.  )

Again, the application does not choose - the implementator does.
 

Anyway,  there is more ways than one to skin a cat. Just keep everything as simple as possible but no simpler. I am sure you are eager to bring this to closure so I will not belabor the point about eager parsing versus lazy parsing  although, as a final point I would just like to state that portability can be handled whether or not the parse is explicitly or implicitly lazy. Enough said on this point.

Thanks for all your input Ranga!
 
 
 
 

Regards,

Ranga.
 
 
 
  

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
 
--------------AD771551279F78EBE6656E05-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 05:49:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28889 for ; Tue, 28 Nov 2000 05:49:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D28684438B; Tue, 28 Nov 2000 04:49:09 -0500 (EST) 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 6759444383 for ; Tue, 28 Nov 2000 04:48:47 -0500 (EST) 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 MAA23914 for ; Tue, 28 Nov 2000 12:49:36 +0200 (IST) From: Joshua_Fox@vocaltec.com Subject: RE: [SIP] multiple location 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 11/28/2000 12:48:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 28 Nov 2000 12:48:15 +0200 This is quite true that we should distinguish between the protocol and the use made of it. On the other hand, the sticker on the ladder does say "don't use this ladder as scaffolding" because some uses for tools are inappropriate, even if they are possible. \\For example, we can do some weird hacks with HTTP or TLS to tunnel through firewalls, but people who are getting started with these protocols vshould be informed that these are not the ideal uses of the protocol. (The wonderful SIP-firewall-tunneling draft gets the balance right, by in explaining a clever hack for SIP-over-TLS to port 443, while also noting that this is an awful hack.) > SIP is just a protocol. Thats it. Its a tool. If you > want device A to call > device B, it tells you how to do that. Like all tools, > you can use them in > many different ways. When you buy a hammer in Home > Depot, does it tell you > whether to use your left hand or right? How many > fingers to grip with it? > The size of the nails to use with it? Of course not. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 05:51:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29720 for ; Tue, 28 Nov 2000 05:51:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 954974439C; Tue, 28 Nov 2000 04:51:09 -0500 (EST) 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 9EAD44439B for ; Tue, 28 Nov 2000 04:50:53 -0500 (EST) 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 MAA23946 for ; Tue, 28 Nov 2000 12:51:42 +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 11/28/2000 12:50:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] call-flow; each user has 2 UAs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 28 Nov 2000 12:50:21 +0200 I'd like to ask a call-flow question. Excuse me if I asked a similar question before, but perhaps I did not state it clearly earlier. What happens if two people EACH have two UA's, each on a different media. This is a reasonable scenario, since people may buy multiple devices or applications, and system integrators may wish to integrate separate applications without altering their software. As a simple example, say that the two medias are audio and video (although in real life, of course, an app/device with video will also likely have audio). Jack Jill Audio <-------------------------------------------------> Audio Video <-------------------------------------------------> Video The important point is that the Audio and Video devices are NOT integrated and have separate UA's, yet we want all four apps/devices to be joined in one "session", with Jack's audio talking to Jill's audio, and Jack's video talking to Jill's video. Perhaps we can assume that Jack's audio and video both have the same SIP URL. We need some sort of four-way session with proper use of SDP to distinguish media types. To add two UA's on the UAS side, we need forking with non-exclusive response from two UA's. We also have to decide how to bring in two UA's on the UAC side. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 09:45:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03223 for ; Tue, 28 Nov 2000 09:45:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4611044346; Tue, 28 Nov 2000 08:45:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 2EF0744336 for ; Tue, 28 Nov 2000 08:44:44 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 28 Nov 2000 08:44:36 -0600 (CST) From: Billy Biggs To: Joshua_Fox@vocaltec.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] call-flow; each user has 2 UAs Message-ID: <20001128084436.B26878@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from Joshua_Fox@vocaltec.com on Tue, Nov 28, 2000 at 12:50:21PM +0200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 28 Nov 2000 08:44:36 -0600 Joshua_Fox@vocaltec.com (Joshua_Fox@vocaltec.com): > As a simple example, say that the two medias are audio and video > (although in real life, of course, an app/device with video will also > likely have audio). > > Jack Jill > Audio <-------------------------------------------------> Audio > Video <-------------------------------------------------> Video > > The important point is that the Audio and Video devices are NOT > integrated and have separate UA's, yet we want all four apps/devices > to be joined in one "session", with Jack's audio talking to Jill's > audio, and Jack's video talking to Jill's video. Perhaps we can assume > that Jack's audio and video both have the same SIP URL. The session you describe is an abstraction layer above a SIP session. I see two ways of handling this: Remote The first method is to have a SIP call | SIP between the remote side and some Master controller which communicates to the A and / \ ? V apps and incorporates their addresses Video Audio into a common SDP. The master can be a 3pcc server if you use SIP to talk to A/V. The second method is simply to have two Remote calls up, and use some other means of | | SIP association higher up. This may simply be Video Audio Jack telling Jill about the other session, or some new header which flags the app telling it to associate the two calls. > We need some sort of four-way session with proper use of SDP to > distinguish media types. To add two UA's on the UAS side, we need > forking with non-exclusive response from two UA's. We also have to > decide how to bring in two UA's on the UAC side. You don't need to get so complicated. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 09:53: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 JAA06471 for ; Tue, 28 Nov 2000 09:53:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1ED584439A; Tue, 28 Nov 2000 08:53:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 7E44344390 for ; Tue, 28 Nov 2000 08:52:53 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA04890; Tue, 28 Nov 2000 09:52:42 -0500 (EST) Message-ID: <3A23C6BA.F3A92AB7@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Howard Hart Cc: Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt References: <3A22AADC.6EC40BF4@ipdialog.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, 28 Nov 2000 09:52:42 -0500 Content-Transfer-Encoding: 7bit Howard Hart wrote: > > Jonathan and Henning, > > I think this is a great shot at tunneling SIP and RTP through Firewalls, > though you may want to add the following caveats to section 6: > > 1) Wrt corporate tunneling, high-bandwidth voice traffic has a distinct > network signature vs. (relatively) low-bandwidth Web traffic. If you blast > voice traffic, encrypted or unencrypted over Web ports, it's going to stick out > like a sore thumb even using the crudest network monitoring tools. ISS and the > other network intrusion detection packages may even flag it as a Netbus, > BackOrifice, or Distributed Denial of Service attack signature. Most network > administrators will shut the originating host/port down immediately and ask > questions later. I'm not sure whether that's a problem, as voice bandwidth is generally much lower than web retrievals. (As low as 8 kb/s vs. a few hundred kilo*bytes*/second on my desktop to many web servers. If I download a piece of software, it will easily consume as much bandwidth as a phone call: 3 minute call = 180 seconds = 180 kBytes, which is smaller than many individual web pages.) > > 2) The Internet backbone itself has been heavily optimized (some might say > almost too optimized) for port 80 traffic, and is moving in that direction (as This is bogus, except for the web caching that some ISPs (but, fortunately, by no means all ISPs) do. Routers don't know about port 80. > much as is feasible) for port 443/HTTPS. Increasingly, ISPs are using Web > caching engines to limit this traffic across their backbones. Case in point--I > used Checkpoint's encrypted VPN product in a previous company to connect an > overseas location to our site (encrypted payloads, port numbers stay the same). > Our remote site wanted to access our internal Web server. Unfortunately, one of > the intermediate ISPs was using a Web caching product, which resulted in the > caching engine intercepting, then attempting to originate an (unauthorized) > port 80 access to our internal Web server on the remote end's behalf, with the > expected (non)result. The answer from the ISP was, of course, "well it works > fine for all our normal customers--EOM". I think you'd see some very > interesting side effects if you applied a tunneled RTP stream to this or other > kinds of caching servers on port 80. > Granted, 443/SSL-caching is a much more difficult problem, equating to a > man-in-the- middle attack--maybe even unsolvable, but given the monetary > inceptive is huge to come up with a solution here too, partial or otherwise.... Much of 443 traffic is inherently uncacheable, as it is for things like forms responses from web orders. I doubt that even the looniest ISP would want to return your airline booking confirmation page or bank balance to me. Also, unless the cache has the certificate of the origin server, intercept is just not possible. I doubt that Citibank, say, would hand out their private key to random ISPs. > > Howard Hart > ipDialog, Inc. > -- 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 Nov 28 10:05: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 KAA12022 for ; Tue, 28 Nov 2000 10:05:19 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 43207443A7; Tue, 28 Nov 2000 09:05:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.pingtel.com (mail.pingtel.com [216.91.1.131]) by lists.bell-labs.com (Postfix) with ESMTP id 63EF7443A3 for ; Tue, 28 Nov 2000 09:04:42 -0500 (EST) Received: from bbk.pingtel.com (pool0053.cvx21-bradley.dialup.earthlink.net [209.179.192.53]) by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id JAA01068; Tue, 28 Nov 2000 09:02:24 -0500 Message-Id: <4.3.2.7.2.20001127213200.00c7fec0@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Billy Biggs , "Henning G. Schulzrinne" From: Jay Batson Subject: Re: [SIP] New I-D on multiparty conferencing models Cc: Jonathan Rosenberg , SIP List In-Reply-To: <20001120191406.A10494@div8.net> References: <3A19C949.4E3C6BE8@cs.columbia.edu> <20001120123017.B9775@div8.net> <3A19AC4C.782208EC@cs.columbia.edu> <20001120175608.A10358@div8.net> <3A19BBEF.A23163A7@cs.columbia.edu> <20001120185341.A10435@div8.net> <3A19C949.4E3C6BE8@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-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 27 Nov 2000 21:54:25 -0500 > Regardless, lets just talk about the assumptions we're making about >the capability of the clients. > > I don't expect all clients to be able to support: > > - sending audio to multiple locations, and > - mixing audio from multiple sources. > > I don't think your draft should either. Is that unreasonable? Protocols should not be designed with the "probability of implementation" in mind when the motivation for those probabilities is are based on "assumptions" about likely products to be built under market conditions of the moment. Remember Moore's law -- the DSP and memory resources available to vendors (of client products) will change much faster than the protocol changes. Protocols should be designed to specify behavior in ways that are technically logical, defensible, as-minimal-as-should-be, and yet provide flexibility and extensiblility so that they can have a long life, especially if these behaviors "advance the ball" (vs. replicate the status-quo). There should also be an understood, graceful fallback / failure mechanism for what behavior happens if certain protocol features are not implemented in a participating system. IMHO, the requirements placed on clients by the multiparty conferencing I-D meet these requirements. If implementors belive that implementing a component of the protocol falls outside the functional and market constraints for a product being offered at a particular moment in time (given target market, price point, etc.), the implementor can choose to act according to the fallback / failure mechanism. This behavior simply becomes a momentary component of differentiation between competing products. But protocol designers should not make consideration of this choice a determining factor for inclusion in the protocol. If "likelihood of implementation" were a factor in the specification of HTTP, MIME, RFC822, etc., we would have a much less interesting world now than we do. Design for the future -- not the present, keeping Moore's (and Gilder's) laws in mind. Designing for the lowest common denominator is boring. Cheers -jb ---------- Jay Batson Pingtel Corp. jbatson@pingtel.com 781-938-5306 (office) 781-938-9650 (fax) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 10:46:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27835 for ; Tue, 28 Nov 2000 10:46:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CDAED44361; Tue, 28 Nov 2000 09:46:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A757844352 for ; Tue, 28 Nov 2000 09:45:10 -0500 (EST) Received: from dynamicsoft.com ([212.120.151.114]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA14470; Tue, 28 Nov 2000 10:47:26 -0500 (EST) Message-ID: <3A23D287.816415B2@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jainsip@sun.com Cc: sip@lists.bell-labs.com, discussion@sipforum.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] JAIN SIP Factory Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 28 Nov 2000 15:43:03 +0000 Content-Transfer-Encoding: 7bit Dear all, One thing which has been bothering me is having all the create methods for messages and headers on the concrete JainSipFactory. These methods all require that message and header implementations have an empty constructor and then the JainSipFactory invokes all the required set methods with the create method's parameters. I think that this could be quite restrictive for an implementor, and I suggest that the create methods should be defined in interfaces rather than the JainSipFactory class. The JainSipFactory could have createJainSipMessageFactory and createJainSipHeaderFactory methods which create particular implementations of JainSipMessageFactory and JainSipHeaderFactory. [Or we could put these two methods in the JainSipStack.] The implementations of these abstract factories are free to use any constructors they like, and potentially could provide proprietary optimisations such as object pooling. What do people think about this? Another thing about defining messages and headers as interfaces rather than classes, is that the arguments to methods are defined in terms of interfaces. Do we not really want to have an application mixing different implementations? - I don't believe so. Then how can we enforce that say XXX's implementation of the JainSipProvider can only take XXX's implementations of the JAIN SIP interfaces as arguments? Use reflection and throw an exception if the class of the object received doesn't match the expected class? Again your opinions are welcomed Regards, Chris PS - The Public Review period for the JAIN SIP Specification closes today, so I would be grateful if you could send me any additional comments ASAP. All going well, I hope to have the First Public Release available at the SIP Bakeoff next month. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 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 LAA14056 for ; Tue, 28 Nov 2000 11:20:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6863244383; Tue, 28 Nov 2000 10:20:10 -0500 (EST) 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 6CEA44434D for ; Tue, 28 Nov 2000 10:19:41 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id eASGJWB15988 for ; Tue, 28 Nov 2000 17:19:32 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Nov 28 17:19:32 2000 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 28 Nov 2000 17:19:31 +0100 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73E3B@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "Sip (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] multiple calls for IP telephony client Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 28 Nov 2000 17:19:28 +0100 While I was thinking about functionality of the User Agents for IP telephony. I got myself tangled in the following: A call is one or more sessions ----> no problem, all sessions have the same Call_ID This means that if A initiates a call, and B receives the call and B will then add 2 minutes later another session (a text session for relay purposes or a seperate video stream), it will be considered to be the same call? I know that SIP can just do this within the same call_ID via a re-invite. But if B wants the text stream or video stream But if B's session is seen as a new call, does it mean that the IP telephony client is handling 2 seperate calls? I know that technically this does not matter for the client, but practically this may confuse the clients, since most people will deal with one call at the time and not simultaneously. Maybe I am overlooking some things. I hope that you understand my question. :-) A second question is: Can the originator of a session be found in the re-invite? If A calls B with session 1 and B comes then with session 2, the re-invite (adding session 2 to session 1) has then from: B@buffy.com? even that originally the invite (session 1) was reading from: A@Angel.com (A started the call)? I do believe so. (been a long day:-) Thanks for your time. Arnoud _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk ABACUS Lab Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 11:32: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 LAA19573 for ; Tue, 28 Nov 2000 11:32:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3ABB5443AE; Tue, 28 Nov 2000 10:32:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id DDF3F4438A for ; Tue, 28 Nov 2000 10:31:48 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 28 Nov 2000 10:31:40 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Robert Sparks , SIP List Subject: Re: [SIP] Possible REFER problem? Message-ID: <20001128103140.A26989@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Thu, Nov 23, 2000 at 10:36:47PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 28 Nov 2000 10:31:40 -0600 Our situation is as follows: A / \ B C A is in a 3-way call with B and C and wishes to be excused. If C called A, then A has no 'well-known URI' for C. The best address is the Contact. The From is not useful because it may be an unknown URI scheme, or C might be a 3pcc server, or the URI may be stale (or fork)... In our implementation, we use the Contact exclusively. I expect other implementations will also generalize transfer with consultation by instead implementing call handoff, and act similarily. If we REFER B to C and it fails, maybe we'll instead REFER C to B. If some server really needs to be in the signalling path, it should do 3pcc, or mangle the Contact, or act as a transparent SIP proxy... Jonathan discussed why using the Contact is dangerous: > The answer is that URIs most definitely have a context; a place from > which they can be usefully used. In a perfect world with no NATs, > firewalls, or devices that want to know whats going on within the > network, it would work dandy. But thats not reality. The classic > example is an ACD application, where help@helpdesk.com can be routed > to a variety of agents (agent32@host32.helpdesk.com). Sophisticated > software tracks the call status of the various agents, how much volume > they get, etc. Incoming calls MUST come in through this helpdesk proxy > to work. The proxy always record routes. In fact, to enforce this, > the proxy has access to a hosts file with the host32.helpdesk.com > address mapped to an IP address. Outside of this proxy, that hostname > is unroutable. So, if A called B, and then A called C, and C was one > of these operators, the URI returned by C > (agent32@host32.helpdesk.com) will definitely not be useful for B to > use directly. With an ACD application, in order to enforce all calls through the server, the server must perform 3pcc and only SIPly expose itself, or have all of the clients collude with the server and redirect all incoming direct-dialed calls. I don't think a Record-Route'ing proxy with some unroutable client addresses is clean, and I think it is reasonable to have attended transfer fail in these scenarios. If the Contact address is not generally routable (firewalls and NATs), then it should be mangled if the user wishes attended transfer to work, or have calls go through some helper 3pcc box. I see this as the only reasonable solution. > Perhaps these cases are so extreme its not worth worrying about. I > wouldn't be surprised if they don't work in the PSTN either. The PSTN has no concept of a REFER, which is where all this breaks down. Again, the 3-way call: A / \ B C A cannot excuse itself from the call in the PSTN. It can only keep the bridge active. This is acceptable because A is a PBX or similar server. There is no concept of signalling a transfer over the PSTN where the transferred party makes a new call. > So, despite its complexity, I feel compelled to recommend that > Robert's hybrid approach be described in the REFER specification as > the preferred way to do transfer out of consultation, along with a > nice long explanation of why it needs to be so. I'm not sure about the > order though. I suspect that (2) will work in far more cases than (1) > will. I welcome better ideas if anyone has any... It might be better to remove transfer out of consultation from the REFER draft, and maybe do a new draft on attended transfer, discussing these options and also introducing the replaces header from draft-biggs-sip-replaces-00. I really want to be able to have A silently excuse itself from the conference. This will help with many services, including moving transparently to a conference bridge, call park with server, ... -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 12:12:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04373 for ; Tue, 28 Nov 2000 12:12:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5E3B4434D; Tue, 28 Nov 2000 11:12:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (uzura.cisco.com [161.44.3.77]) by lists.bell-labs.com (Postfix) with ESMTP id DFB9F44336 for ; Tue, 28 Nov 2000 11:11:38 -0500 (EST) Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA06702 for ; Tue, 28 Nov 2000 12:10:33 -0500 (EST) Message-ID: <3A23E740.50993938@cisco.com> From: Ameet Kher Reply-To: akher@cisco.com Organization: Cisco Systems 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: multipart/alternative; boundary="------------25E0FFD89B17F900BAF69875" Subject: [SIP] Manyfolks draft 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, 28 Nov 2000 12:11:28 -0500 --------------25E0FFD89B17F900BAF69875 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, Need a clarification on the latest version of Manyfolks draft. What should happen if the UAS receiving an Invite with confirm tag does not have the ability to do QoS. Should a Comet be sent out by the UAS in this case ? The call has proceeded as Best effort and the 183 sent out by the UAS had no "a" line in its SDP body. Thanks Ameet -- ****************************** AMEET KHER, Software Engineer Cisco Systems Tel : (919) 392-8431 --------------25E0FFD89B17F900BAF69875 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,

Need a clarification on the latest version of Manyfolks draft.

What should happen if the UAS receiving an Invite with confirm tag does not have
the ability to do QoS. Should a Comet be sent out by the UAS in this
case ? The call has proceeded as Best effort and the 183 sent out by the UAS had
no "a" line in its SDP body.

Thanks
Ameet 

-- 
******************************
AMEET KHER, Software Engineer
Cisco Systems
Tel : (919) 392-8431
  --------------25E0FFD89B17F900BAF69875-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 14:04:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09320 for ; Tue, 28 Nov 2000 14:04:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7E7CB4439F; Tue, 28 Nov 2000 13:04:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id C2037443B4 for ; Tue, 28 Nov 2000 13:03:44 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 28 Nov 2000 12:31:10 -0600 (CST) From: Billy Biggs To: Robert Sparks Cc: SIP List Message-ID: <20001128123110.A27033@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] Multiple-Transaction REFER Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 28 Nov 2000 12:31:10 -0600 As pointed out earlier by Jonathan, the single-transaction REFER mechanism fails as the REFER may time out. To clean things up, the suggestion is to split up REFER into a sequence of transactions. To start discussion, here are some ideas: 1. REFER looks the same, but it is responded with a 2xx if the far end accepts the REFER and intends to act upon it. 2. A REFERDONE request which signals back that the spawned INVITE completed. Success or failure is indicated in some header (or in the body?). This request requires a header, Refer-CSeq or similar, to indicate which REFER transaction is being completed. Optionally: 3. A REFERSTATUS request which can signal back the call setup progress. Requires a Refer-CSeq header. Optional support by both UAs. 4. A REFERCANCEL request which can attempt to cancel a pending REFER. Requires a Refer-CSeq header. Optional support by both UAs. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 14:41: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 OAA19747 for ; Tue, 28 Nov 2000 14:41:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE2C54435B; Tue, 28 Nov 2000 13:41:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 25AE64433C for ; Tue, 28 Nov 2000 13:40:47 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eASIxKO03359 for ; Wed, 29 Nov 2000 00:29:22 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eAS4s6k22588 for ; Tue, 28 Nov 2000 10:24:07 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569A5.001A59FE ; Tue, 28 Nov 2000 10:17:49 +0530 X-Lotus-FromDomain: HSSBLR From: sunayak@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <652569A5.001A5871.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] Multiple SDP bodies in a SIP message Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 28 Nov 2000 10:17:44 +0530 Hi All ! I had a query regarding SDP message bodies. Is it possible to have multiple SDP bodies in a single SIP message. If so, where would this be applicable ? (Could someone give a scenario/example) Eg: ... ... Thanks in advance Subhash Nayak 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 Nov 28 15: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 PAA28556 for ; Tue, 28 Nov 2000 15:10:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 236294433C; Tue, 28 Nov 2000 14:10:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from godzilla.ipdialog.com (ipsniffers-122.fiasj.net [208.238.222.122]) by lists.bell-labs.com (Postfix) with ESMTP id 7304144336 for ; Tue, 28 Nov 2000 14:09:46 -0500 (EST) 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 MAA00730; Tue, 28 Nov 2000 12:08:39 -0800 Message-ID: <3A2410C7.D9EAF24A@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: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt References: <3A22AADC.6EC40BF4@ipdialog.com> <3A23C6BA.F3A92AB7@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 28 Nov 2000 12:08:39 -0800 Content-Transfer-Encoding: 7bit Hi Henning, See responses below: "Henning G. Schulzrinne" wrote: > Howard Hart wrote: > > > > Jonathan and Henning, > > > > I think this is a great shot at tunneling SIP and RTP through Firewalls, > > though you may want to add the following caveats to section 6: > > > > 1) Wrt corporate tunneling, high-bandwidth voice traffic has a distinct > > network signature vs. (relatively) low-bandwidth Web traffic. If you blast > > voice traffic, encrypted or unencrypted over Web ports, it's going to stick out > > like a sore thumb even using the crudest network monitoring tools. ISS and the > > other network intrusion detection packages may even flag it as a Netbus, > > BackOrifice, or Distributed Denial of Service attack signature. Most network > > administrators will shut the originating host/port down immediately and ask > > questions later. > > I'm not sure whether that's a problem, as voice bandwidth is generally > much lower than web retrievals. (As low as 8 kb/s vs. a few hundred > kilo*bytes*/second on my desktop to many web servers. If I download a > piece of software, it will easily consume as much bandwidth as a phone > call: 3 minute call = 180 seconds = 180 kBytes, which is smaller than > many individual web pages.) If the average Web page retrieval required 100+ kbytes/second, I don't think the average user on their 28.8 baud, 3-5 kbytes/second (w/VJ compression) modem would do much web surfing :-), but I get your point. My contention is divergence from Web traffic signatures will be highly dependent on a number of cumulative factors, from your locally provisioned bandwidth, to your usage patterns, to the number of times you access the same server, to the sensitivity of your intrusion detection package, to how long you stay on the phone, etc. If you throw in sustained, encrypted RTP packet rate signatures at 25-50 pps over several minutes with the added burden that only a small percentage of Web traffic is encrypted/port 443, it will probably trigger the alarms, but your mileage will vary depending on the level of paranoia at your local site. > > > > > > 2) The Internet backbone itself has been heavily optimized (some might say > > almost too optimized) for port 80 traffic, and is moving in that direction (as > > This is bogus, except for the web caching that some ISPs (but, > fortunately, by no means all ISPs) do. Routers don't know about port 80. Agreed, my wording was poor. More accurately, ISPs are deploying web caching engines at their edges to eliminate/optimize redundant HTTP/port 80 traffic over their backbones, especially when they're being used for transit vs. direct access to Web servers within their networks. > > > > much as is feasible) for port 443/HTTPS. Increasingly, ISPs are using Web > > caching engines to limit this traffic across their backbones. Case in point--I > > used Checkpoint's encrypted VPN product in a previous company to connect an > > overseas location to our site (encrypted payloads, port numbers stay the same). > > Our remote site wanted to access our internal Web server. Unfortunately, one of > > the intermediate ISPs was using a Web caching product, which resulted in the > > caching engine intercepting, then attempting to originate an (unauthorized) > > port 80 access to our internal Web server on the remote end's behalf, with the > > expected (non)result. The answer from the ISP was, of course, "well it works > > fine for all our normal customers--EOM". I think you'd see some very > > interesting side effects if you applied a tunneled RTP stream to this or other > > kinds of caching servers on port 80. > > Granted, 443/SSL-caching is a much more difficult problem, equating to a > > man-in-the- middle attack--maybe even unsolvable, but given the monetary > > inceptive is huge to come up with a solution here too, partial or otherwise.... > > Much of 443 traffic is inherently uncacheable, as it is for things like > forms responses from web orders. I doubt that even the looniest ISP > would want to return your airline booking confirmation page or bank > balance to me. Also, unless the cache has the certificate of the origin > server, intercept is just not possible. I doubt that Citibank, say, > would hand out their private key to random ISPs. True, and as I stated above, maybe unsolvable, but for a sample of where pieces of this might come into play later on, check out http://www.f5.com/f5products/bigip/ecommerce, one of the more popular Web load-balancers. The advantage here is you offload encryption and key negotiation from individual servers in a large server farm and place the burden in hardware on the load-balancer. The question then becomes an ISP/SysAdmin policy issue as to whether you can locate your remote tunneling Proxy in front of or behind the load-balancer, and what's the impact when the load-balancer assumes all traffic on port 443 is HTTP only. NOTE: This is obviously NOT an issue for your scheme today. Just something to consider or maybe even take advantage of in the future. 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 Tue Nov 28 16:42:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28802 for ; Tue, 28 Nov 2000 16:42:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C011B44372; Tue, 28 Nov 2000 15:42:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06s.us.nortel.com (h50s48a140n47.user.nortelnetworks.com [47.140.48.50]) by lists.bell-labs.com (Postfix) with ESMTP id E5F2344352 for ; Tue, 28 Nov 2000 15:41:39 -0500 (EST) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 28 Nov 2000 16:39:17 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 28 Nov 2000 16:39:12 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E80517BA29@zwdld001.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05983.A09A0490" X-Orig: Subject: [SIP] I-D ACTION:draft-hamer-sip-session-auth-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 28 Nov 2000 16:39: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_01C05983.A09A0490 Content-Type: text/plain; charset="iso-8859-1" I would like to draw your attention to this new I-D. All comments and questions are welcomed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hamer-sip-session-auth-00.txt ABSTRACT Current proposals dealing with authorization of media streams for multimedia services like IP telephony and video assume a pre- established relationship between elements of the network (e.g. session managers, edge routers, policy servers and end hosts). In some environments, however, such pre-established relationships may not exist either due to the complexity of creating these associations a priori (e.g. in a network with many elements), or due to the different business entities involved (e.g. service provider and access provider), or due to the dynamic nature of these associations (e.g. in a mobile environment). In this document, we describe scenarios where there is no pre- established relationship between entities and describe mechanisms for exchanging information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the session and bearer control planes. Regards, Louis-Nicolas Hamer ------_=_NextPart_001_01C05983.A09A0490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I-D ACTION:draft-hamer-sip-session-auth-00.txt

I would like to draw your attention to = this new I-D. All comments and questions are welcomed.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-hamer-sip-se= ssion-auth-00.txt

ABSTRACT

Current proposals dealing with = authorization of media streams for
multimedia services like IP telephony = and video assume a pre-
established relationship between = elements of the network (e.g.
session managers, edge routers, = policy servers and end hosts). In
some environments, however, such = pre-established relationships may
not exist either due to the = complexity of creating these
associations a priori (e.g. in a = network with many elements), or due
to the different business entities = involved (e.g. service provider
and access provider), or due to the = dynamic nature of these
associations (e.g. in a mobile = environment).
In this document, we describe = scenarios where there is no pre-
established relationship between = entities and describe mechanisms
for exchanging information between = network elements in order to
authorize the use of resources for a = service and to co-ordinate
actions between the session and = bearer control planes.


Regards,
Louis-Nicolas Hamer

------_=_NextPart_001_01C05983.A09A0490-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 18:50: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 SAA21324 for ; Tue, 28 Nov 2000 18:50:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8112E44369; Tue, 28 Nov 2000 17:50:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id D71F344352 for ; Tue, 28 Nov 2000 17:49:36 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id SAA10481; Tue, 28 Nov 2000 18:44:24 -0500 (EST) Message-ID: <3A244486.EAB96A74@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP - Issues to be resolved Content-Type: multipart/alternative; boundary="------------8BBB7848F980FB1C19A69CF1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 28 Nov 2000 18:49:26 -0500 --------------8BBB7848F980FB1C19A69CF1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Chris, A few closing comments on this string of exchanges (edited out all but the relevant parts to keep the reading simple). Regards Ranga. ------------------------------------------------------------------------ >> A design issue not discussed below: >> >> Whenever there is more than one header to be returned (via headers >> for example), you return an array. An array is easy to walk >> through. However, I would think it more useful to return a >> collection of some sort that supports additional methods such as >> checking if an address exists in the list of headers returned etc. >> That might be of some use to an implementation. If you define the >> returned type as an array of headers, there is no way to extend the >> class to support additional functionality. May I suggest adding a >> collection class interface for collections of SIP Headers (and that >> can be specialized by implementations to support additional query >> methods etc.), say something like SIPHeaderList > > I initially wanted to return a Vector, but was told that an array was > preferable for API's. Besides, any addition of functionality would be > purely for the implementor's benefit and would not be available > (without using reflection anway) to the application. My point was that if you returned an array, you could not extend it so IMHO, Vector would work better (you can extend the class and add whatever functionality you want). This would make an implementer's life easier and the implementation more elegant. >> > >> >> Ah! My understanding was correct then. >> >> OK. Perhaps this would be too much of a change for you to consider >> but let me make a suggestion anyway .... >> >> I think formatting headers should be considered under a different >> set of API. Here is what I am suggesting >> >> 1. Get rid of the setXXX interfaces (the parser will have direct >> access to the classes and does not need them and it will cut down >> the size of the API). >> >> 2. Have a SIPMessageFormatter interface who'se sole job it is to >> format output messages. This can have methods to format the >> different outgoing messages and will throw parse exceptions if the >> strings that it gets are incorrect. The MessageFormatter interface >> takes as parameter values only Strings. >> >> Concretely, for example: >> >> public interface SIPMessageFormatter { >> public String createFromMessage( String from , String tag) >> throws SIPParseException; >> >> ..................... >> >> } >> >> It would be slower for an implementation to extract the same >> information out of a structure and hand it to a parser for >> validation (IMHO). A "loose implementation" may not want to be >> bothered with validation at all and leave it to the reciever to >> reject the mesage, thereby making the implementation faster or it >> may do very cursory checking. >> > > This is a major change at this stage (public review technically closes > today) - I personally don't think it's very OO, but I would be > interested to hear other people's opinons. I agree that it is maybe not OOcentric and that it is a late change but it does follow the end to end argument: i.e. the sender does not necessarily have to check for correctness of the input because it can rely on the receiver doing so. I think this is a strong argument in its favor. It also cuts down on the number of APIs substantially and removes the overhead of formatting inputs to Strings from other types of inputs and checking these with the parser. I think it can simplify things and give you the functionality you need. >> OK Glad you buy that one. > > I was just wondering what the message of a JainSipParseException > thrown from a set method should contain - the value passed in? Perhaps > we should add a string field to the JainSipParseException (say > unparsable) which can be whatever the parser was unable to parse? Then > the message can be left for explanatory comments. I think the portion of the header that the set method was unable to parse would be the relevant information to return. However, if you buy into eliminating setXXX methods and having a MessageFormatter instead, the point is moot :) Regards Ranga -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------8BBB7848F980FB1C19A69CF1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
 

Chris,

A few closing comments on this string of exchanges (edited out all but the relevant parts to keep the reading simple).

Regards

Ranga.

A design issue not discussed below:

Whenever there is more than one header to be returned (via  headers for example), you return an array.  An array is easy to walk through. However,  I would think it more useful to return a collection of some sort that supports additional methods such as checking if an address exists in the list of headers returned etc. That might be of some use to an implementation.  If you define the returned type as an array of headers, there is no way to extend the class to support additional functionality.  May I suggest adding a collection class interface for collections of SIP Headers (and that can be specialized by implementations to support additional query methods etc.), say something like SIPHeaderList

I initially wanted to return a Vector, but was told that an array was preferable for API's. Besides, any addition of functionality would be purely for the implementor's benefit and would not be available (without using reflection anway) to the application.


My point was that if you returned an array, you could not extend it so IMHO,  Vector would work better (you can extend  the class and add whatever functionality you want). This would make an implementer's life easier and the implementation more elegant.
 

 
Ah! My understanding was correct then.

OK. Perhaps this would be too much of a change for you to consider but let me make a suggestion anyway ....

I think formatting headers should be considered under a different set of API.  Here is what I am suggesting

1. Get rid of the setXXX interfaces (the parser will have direct access to the classes and does not need them and it will cut down the size of the API).

2. Have a  SIPMessageFormatter interface who'se sole job it is to format output messages.  This can have methods to format the different outgoing messages and will throw parse exceptions if the strings that it gets are incorrect. The MessageFormatter interface takes as parameter values only Strings.

Concretely,  for example:

public interface SIPMessageFormatter {
        public String createFromMessage( String from ,  String tag) throws SIPParseException;

    .....................

}

It would be slower for an implementation to extract the same information out of a structure and hand it to a parser for validation (IMHO). A "loose implementation" may not want to be bothered with validation at all and leave it to the reciever to reject the mesage, thereby making the implementation faster or it may do very cursory checking.
 

This is a major change at this stage (public review technically closes today)  - I personally don't think it's very OO, but I would be interested to hear other people's opinons.


I agree that it is maybe not OOcentric and that it is a late change but it  does follow the end to end argument:  i.e.  the sender does not necessarily have to check for correctness of the input  because it can rely on the receiver doing so.  I think this is a strong argument in its favor.  It also cuts down on the number of APIs substantially and removes the overhead of formatting inputs to Strings  from other types of inputs and checking these with the parser. I think it can simplify things and give you the functionality you need.
 
 
 

OK Glad you buy that one.
I was just wondering what the message of a JainSipParseException thrown from a set method should contain - the value passed in? Perhaps we should add a string field to the JainSipParseException (say unparsable) which can be whatever the parser was unable to parse? Then the message can be left for explanatory comments.
I think the portion of the header that the set method was unable to parse would be the relevant information to return. However, if you buy into eliminating setXXX methods and having a MessageFormatter instead, the point is moot :)

Regards
Ranga 

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

  --------------8BBB7848F980FB1C19A69CF1-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Nov 28 19:53: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 TAA16693 for ; Tue, 28 Nov 2000 19:53:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 252DA44352; Tue, 28 Nov 2000 18:53:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id F0F364434F for ; Tue, 28 Nov 2000 18:52:05 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id TAA11757; Tue, 28 Nov 2000 19:46:54 -0500 (EST) Message-ID: <3A24532B.BF6FD8A3@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: jainsip@sun.com, sip@lists.bell-labs.com, discussion@sipforum.org Subject: Re: [SIP] JAIN SIP Factory References: <3A23D287.816415B2@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------241F33EEB785EB7883DE93DB" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 28 Nov 2000 19:51:55 -0500 --------------241F33EEB785EB7883DE93DB Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Chris Harris wrote: > Dear all, > > One thing which has been bothering me is having all the create methods > for messages and headers on the concrete JainSipFactory. These methods > all require that message and header implementations have an empty > constructor and then the JainSipFactory invokes all the required set > methods with the create method's parameters. There is probably a very good reason for these API but I have not understood the motivation . How do you envision these API being used (When would an application want to create Headers in this fashion? Are these to be interfaces to a parser? ) > > > I think that this could be quite restrictive for an implementor, and I > suggest that the create methods should be defined in interfaces rather > than the JainSipFactory class. > The JainSipFactory could have > createJainSipMessageFactory and createJainSipHeaderFactory methods which > create particular implementations of JainSipMessageFactory and > JainSipHeaderFactory. [Or we could put these two methods in the > JainSipStack.] The implementations of these abstract factories are free > to use any constructors they like, and potentially could provide > proprietary optimisations such as object pooling. What do people think > about this? If you need to create Headers in this fashion, I would agree with your suggestion above. > > > Another thing about defining messages and headers as interfaces rather > than classes, is that the arguments to methods are defined in terms of > interfaces. Do we not really want to have an application mixing > different implementations? - I don't believe so. In the utopian world of true portability, this would work but in reality, I suppose this would be a bad idea. > Then how can we enforce > that say XXX's implementation of the JainSipProvider can only take XXX's > implementations of the JAIN SIP interfaces as arguments? Use reflection > and throw an exception if the class of the object received doesn't match > the expected class? Again your opinions are welcomed Reflection would be a good way of checking this (or one could use something like a UUID I suppose). > > > Regards, > Chris > > PS - The Public Review period for the JAIN SIP Specification closes > today, so I would be grateful if you could send me any additional > comments ASAP. All going well, I hope to have the First Public Release > available at the SIP Bakeoff next month. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------241F33EEB785EB7883DE93DB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Harris wrote:

Dear all,

One thing which has been bothering me is having all the create methods
for messages and headers on the concrete JainSipFactory. These methods
all require that message and header implementations have an empty
constructor and then the JainSipFactory  invokes all the required set
methods with the create method's parameters.


There is probably a very good reason for these API but I have not understood the motivation . How do you envision these API being used (When would an application  want to create Headers in this fashion?  Are these to be interfaces to a parser?  )

 

I think that this could be quite restrictive for an implementor, and I
suggest that the create methods should be defined in interfaces rather
than the JainSipFactory class.

The JainSipFactory could have
createJainSipMessageFactory and createJainSipHeaderFactory methods which
create particular implementations of JainSipMessageFactory and
JainSipHeaderFactory. [Or we could put these two methods in the
JainSipStack.] The implementations of these abstract factories are free
to use any constructors they like, and potentially could provide
proprietary optimisations such as object pooling. What do people think
about this?


If you need to create Headers in this fashion, I would agree with your suggestion above.

 

Another thing about defining messages and headers as interfaces rather
than classes, is that the arguments to methods are defined in terms of
interfaces. Do we not really want to have an application mixing
different implementations? - I don't believe so.


In the utopian world of true portability, this would work but in reality, I suppose this would be a bad idea.
 
 

Then how can we enforce
that say XXX's implementation of the JainSipProvider can only take XXX's
implementations of the JAIN SIP interfaces as arguments? Use reflection
and throw an exception if the class of the object received doesn't match
the expected class? Again your opinions are welcomed


Reflection would be a good way of checking this (or one could use something like a UUID I suppose).
 

 

Regards,
Chris

PS - The Public Review period for the JAIN SIP Specification closes
today, so I would be grateful if you could send me any additional
comments ASAP. All going well, I hope to have the First Public Release
available at the SIP Bakeoff next month.

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

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------241F33EEB785EB7883DE93DB-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 07: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 HAA07698 for ; Wed, 29 Nov 2000 07:50:19 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F24C44348; Wed, 29 Nov 2000 06:50:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 2A21844341 for ; Wed, 29 Nov 2000 06:49:08 -0500 (EST) Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eATCmx423454 for ; Wed, 29 Nov 2000 13:48:59 +0100 (MET) Received: from uabx04c384.uab.ericsson.se.uab.ericsson.se (uabx04c384 [134.138.229.144]) by ms.uab.ericsson.se (8.11.1/8.11.1/uab-3.3) with ESMTP id eATCmwC25407 for ; Wed, 29 Nov 2000 13:48:58 +0100 (MET) Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se.uab.ericsson.se (8.8.7/client-1.3uab1) id NAA16285; Wed, 29 Nov 2000 13:48:57 +0100 (MET) Message-ID: <3A24FB38.F86225E1@uab.ericsson.se> From: Bertil Engelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.74C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: SIP@lists.bell-labs.com References: <9007j9$vp6$1@lux2.datacom-lab.uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] RECORD-ROUTE/ROUTE requirements Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 13:48:57 +0100 Content-Transfer-Encoding: 7bit This discussion seems endless 8-). There are a lot of implementation details discussed. What I wonder is what the requirements are on ROUTE RECORD-ROUTE. What's the "really" purpose with these headers ? What do they have to support ? If we can agree on the requirements for these headers maybe it's easier to find the best way to "implement" this in the specification ? The main purpose with RECORD-ROUTE/ROUTE as I understand it is that a server can make shure it will get all new requests for a certain call-leg by adding a RECORD-ROUTE to the first (and consequtive) request. The first requirement on ROUTE is that it has to include an address so that a SIP server (or client) can send the next request to the correct server. The first issue I see is how specific this address should be ? Should it specify a specific host (like maddr in a SIP-URL) or is it enough to find one of the hosts in the server and then it's up to the implementation of that server to find the right host for this call ? The way I see it is that this is implementation dependent. It's up to each server implementation to decide how specific the address is that it puts into RECORD-ROUTE/ROUTE. So depending on how robust a server wants to be it might implement this in different ways. Should the specification require a certain robustness in a server ? The next issue I see is port number. Today you have to use the same port number from both caller and callee because the same ROUTE is used in both directions. Should it be possible to use different port numbers ? I would say yes to this. If a server wants to have different port numbers it should have the possibility to do so. A similar issue is transport. Should it be possible to have different transport types in the two directions ? If a proxy is doing transport conversion I think it would be nice if you can specify the different types dependent on direction of the request. ---- ---- ---- ---- ---| P1 |---| P2 |---| P3 |---| P4 |--- ---- ---- ---- ---- What I mean by this is that if P3 uses UDP towards P2 and TCP towards P4 maybe it wants to tell P2 and P4 what they should use in the next request. Of course P2 and P4 could remember this but if e.g. P2 does not RECORD-ROUTE P1 will not know what transport to use towards P3 unless this is said in ROUTE. Another issue is identification. A server have to be able to put some identification in RECORD-ROUTE/ROUTE so that when the next request arrives it can find which call states to use for this request. Certain server implementations maybe find it more optimal to put the state information in the message instead of an identifier. So I beleave both possibilities needs to be supported. Have I forgot something ?? So from this reasoning I draw the conclusion that a server needs the possibility to put in an address (host + port), a transport and an identification/state in RECORD-ROUTE/ROUTE. Since the address and transport part have to be used by other servers (clients) this information have to be detailed specified in the SIP specification so that each server knows where to find these parts. How the identification/state part looks like is implementation dependent and does not need to be as detailed as the other parts. It only need to be so detailed so that the identification/state part can be sent to the next server by the previous server in the ROUTE chain. How a server use this part is up to each server and don't need to be specified (maybe as examples). So if I now go down to details I see different ways of "implementing" the "requirements" in the specification. I think I can atleast say that the identification part MUST be a URI since it's going to be sent to the next server as a request URI. But what a server have put into the URI is up to him. The more controversial parts I guess is the address and the transport. Should they be RECORD-ROUTE/ROUTE parameters or URI parameters ? Personally I prefere RECORD-ROUTE/ROUTE parameters because that means I don't have to look inside the ROUTE-URI and that makes me more future proof towards possibly new types of URIs. The other possibility that has been discussed is to only allow SIP-URL as URI in ROUTE and put the address in there as today (maddr). I don't like this solution because if a new type of URI pops up in the future that a server needs to put in as identification it can't do it directly. Instead it has to convert it into a SIP-URL in some way. The possibility to have different portnumbers and/or transport in the two directions I beleave can be solved as Jonathan described. _IF_ a server wants to use different address (port) or transport in the two directions it has to modify it's own RECORD-ROUTE when the response is sent back. Since this can be done already today I wonder if the specification needs to say much about this (maybe as examples). However I see a risk in this behaviour and that is that a server might modify the wrong RECORD-ROUTE by mistake and it will be very tricky to find which server it was that did the modification unless you have logs from all servers. That's all for now folks. Maybe someone should set up a discussion about this during the bakeoff ?? -- 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 Nov 29 09:36:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15331 for ; Wed, 29 Nov 2000 09:36:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 918AA4436B; Wed, 29 Nov 2000 08:33:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 51C2744341 for ; Wed, 29 Nov 2000 05:31:59 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02192; Wed, 29 Nov 2000 06:31:49 -0500 (EST) Message-Id: <200011291131.GAA02192@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-session-timer-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: Wed, 29 Nov 2000 06:31:49 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-04.txt Pages : 24 Date : 28-Nov-00 This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines a new general header, Session-Expires, which conveys the lifetime of the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-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-session-timer-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-session-timer-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: <20001128134644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134644.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 09:38: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 JAA16263 for ; Wed, 29 Nov 2000 09:38:50 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF56044382; Wed, 29 Nov 2000 08:33:24 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 1E11244341 for ; Wed, 29 Nov 2000 05:32:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02265; Wed, 29 Nov 2000 06:31:54 -0500 (EST) Message-Id: <200011291131.GAA02265@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-call-flows-02.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 29 Nov 2000 06:31:53 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Telephony Call Flow Examples Author(s) : A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J. Rosenberg, K. Summers, H. Schulzrinne Filename : draft-ietf-sip-call-flows-02.txt Pages : 202 Date : 28-Nov-00 This document gives examples of SIP (Session Initiation Protocol) call flows for IP telephony. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers, and Gateways to the PSTN (Public Switch Telephone Network). IP telephony scenarios include SIP Registration, SIP to SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway via SIP. Call flow diagrams and message details are shown. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ANSI ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Example SIP messages used for testing during SIP 'bakeoff' events include SIP 'torture test' messages, and messages with invalid parameters, methods, and tags. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-call-flows-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-call-flows-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-call-flows-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-call-flows-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134657.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 09:46: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 JAA19124 for ; Wed, 29 Nov 2000 09:46:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 410B44436A; Wed, 29 Nov 2000 08:46:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 1AD3D44366 for ; Wed, 29 Nov 2000 08:45:57 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 29 Nov 2000 14:45:49 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA07848; Wed, 29 Nov 2000 15:44:25 +0100 (BST) From: "Jo Hornsby" To: "Bertil Engelholm" , Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements Message-ID: <003201c05a12$de330290$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: <3A24FB38.F86225E1@uab.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 29 Nov 2000 14:44:25 -0000 Content-Transfer-Encoding: 7bit > This discussion seems endless 8-). Indeed. And there I was hoping that we would have this sorted for the Bake-Off. Oh well. > The main purpose with RECORD-ROUTE/ROUTE as I > understand it is that a server can make shure it will > get all new requests for a certain call-leg by adding > a RECORD-ROUTE to the first (and consequtive) request. Exactly. And that is why I think we should mandate (i.e., MUST) that it is a SIP URL with either no transport parameter, or a transport parameter that matches /UDP/i. If these conditions are not met, then we cannot guarantee that a client will be able to route successfully. As an analogy, consider the fact that UDP is a MUST. I wouldn't be surprised if someone writes something that doesn't do UDP, because TLS is essential (for some reason). Now they can't expect to be able to interoperate, but doubtless that won't matter, since the parameters of the network this non-UDP-supporting-something is going to be running in will ensure that it can interoperate with whatever it needs to. In the same way, someone might one day insert a non-SIP URI into a Record-Route, but they can't expect it to work unless they know that the devices in the network are controlled such that they'll understand this non-SIP URI. > The first requirement on ROUTE is that it has to include > an address so that a SIP server (or client) can send the > next request to the correct server. The first issue I > see is how specific this address should be ? It MUST be specific enough such that 1.4.2 lookup procedures _and nothing else_ will resolve to that same (or similar in a farm, or whatever) proxy. > The next issue I see is port number. Today you have > to use the same port number from both caller and callee > because the same ROUTE is used in both directions. > Should it be possible to use different port numbers ? > I would say yes to this. If a server wants to have > different port numbers it should have the possibility > to do so. Well, if a proxy is prepared to modify the Record-Route in the response, then it is free to expose a different port to callee/caller. > A similar issue is transport. Should it be possible to > have different transport types in the two directions ? No, it MUST be UDP. > Another issue is identification. A server have to be > able to put some identification in RECORD-ROUTE/ROUTE > so that when the next request arrives it can find which > call states to use for this request. Certain server > implementations maybe find it more optimal to put > the state information in the message instead of an > identifier. So I beleave both possibilities needs to > be supported. Indeed. But one by no means rules out the other. > Have I forgot something ?? No, I think you got it pretty much covered. &:) > The more controversial parts I guess is the address > and the transport. Should they be RECORD-ROUTE/ROUTE > parameters or URI parameters ? Personally I prefere > RECORD-ROUTE/ROUTE parameters because that means I > don't have to look inside the ROUTE-URI and that makes > me more future proof towards possibly new types of URIs. > > The other possibility that has been discussed is to > only allow SIP-URL as URI in ROUTE and put the address > in there as today (maddr). I don't like this solution > because if a new type of URI pops up in the future that > a server needs to put in as identification it can't do > it directly. Instead it has to convert it into a SIP-URL > in some way. If a proxy needs to embed exotic URIs (or whatever) in Record-Route, then I think it should have to suffer all the pain involved. If we use anything other than UDP SIP URLs, I can't see how we can guarantee interoperability. 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 Wed Nov 29 10:42: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 KAA11897 for ; Wed, 29 Nov 2000 10:42:33 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E40444366; Wed, 29 Nov 2000 09:42:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1F4D244341 for ; Wed, 29 Nov 2000 09:41:20 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA23897; Wed, 29 Nov 2000 10:43:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 10:39:17 -0500 Message-ID: From: Jonathan Rosenberg To: "'sip@lists.bell-labs.com'" Cc: "'sip-implementors@cs.columbia.edu'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C05A1A.881AAE54" Subject: [SIP] FW: I-D ACTION:draft-rosenberg-sip-3pcc-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 29 Nov 2000 10:39: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_000_01C05A1A.881AAE54 Content-Type: text/plain; charset="iso-8859-1" Folks, I wanted to call your attention to this updated 3pcc document. It deals with implementation issues that have come up since the publication of the original draft. Note that, specifically, it no longer recommends carrying SDP in the ACK, but rather using a re-INVITE. It talks about QoS integration, as discussed by Gonzalo at past meetings. It also includes some notes at the end on SIP features that you really, really, *really* want to support so that your phone, PC, or whatever, can receive features and services provided by a controller. As such, I would strongly recommend that people who build UAs take a look at this draft, and plan on supporting the features discussed there. If anyone has questions on the value of doing this, feel free to contact me. --- 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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, November 24, 2000 6:01 PM To: IETF-Announce Subject: I-D ACTION:draft-rosenberg-sip-3pcc-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Third Party Call Control in SIP Author(s) : J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo Filename : draft-rosenberg-sip-3pcc-01.txt Pages : 15 Date : 22-Nov-00 This document discusses the usage of the Session Initiation Protocol (SIP) for third party call control. Third party call control refers to the ability of one entity to create a call in which communications is actually between other parties. We present a SIP mechanism for accomplishing third party call control that does not require any extensions or changes to SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-3pcc-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-rosenberg-sip-3pcc-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-rosenberg-sip-3pcc-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_000_01C05A1A.881AAE54 Content-Type: message/rfc822 To: Subject: Date: Wed, 29 Nov 2000 10:39:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C05A1A.881AAE54" ------_=_NextPart_002_01C05A1A.881AAE54 Content-Type: text/plain ------_=_NextPart_002_01C05A1A.881AAE54 Content-Type: application/octet-stream; name="ATT05945.txt" Content-Disposition: attachment; filename="ATT05945.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001122145926.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-3pcc-01.txt ------_=_NextPart_002_01C05A1A.881AAE54 Content-Type: message/external-body; site="internet-drafts"; dir="draft-rosenberg-sip-3pcc-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C05A1A.881AAE54-- ------_=_NextPart_000_01C05A1A.881AAE54-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 11:45: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 LAA04991 for ; Wed, 29 Nov 2000 11:45:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 32A8944341; Wed, 29 Nov 2000 10:45:10 -0500 (EST) 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 23A884433A for ; Wed, 29 Nov 2000 10:44:58 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 29 Nov 2000 16:44:00 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id QAA10997; Wed, 29 Nov 2000 16:43:58 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 802569A6.005BD99A ; Wed, 29 Nov 2000 16:43:14 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: "Jo Hornsby" Cc: "Bertil Engelholm" , SIP@lists.bell-labs.com Message-ID: <802569A6.005BD7C2.00@marconicomms.com> Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements 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, 29 Nov 2000 16:43:20 +0000 Is it now generally agreed that the requirement in 6.43.2 for clients to set up the Route name-addr using Contact/From headers (excluding maddr and port) should be removed ? This seems to be the fundamental problem. K . Robinson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 11:53: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 LAA07760 for ; Wed, 29 Nov 2000 11:53:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CC4B5443B8; Wed, 29 Nov 2000 10:48:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 298C3443B6 for ; Wed, 29 Nov 2000 10:47:20 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 29 Nov 2000 10:47:02 -0600 (CST) From: Billy Biggs To: Rohan Mahy Cc: SIP List Message-ID: <20001129104702.A28481@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] REFER for Remote Device Control Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 10:47:02 -0600 The sip-peer-3pcc draft discusses providing PHONECTL functionality using REFER. To send a BYE on a specific call leg, the draft uses a Refer-To URI of: To indicate a request to REGISTER as a specific user, the draft uses: I strongly believe that this sort of behavior is outside the scope of REFER. The meaning of the request is hidden in an obfuscated URI, which cannot provide enough information to identify which call-leg is being referenced. [1] I am rewriting the PHONECTL draft, splitting the commands into new methods. For example, LOGIN (ask the UA to REGISTER) and HANGUP (ask the UA to leave a session). This keeps the intent clear, and helps the UA maintain a seperate authentication model for these device control extensions. I hope to have a draft ready this week, but would be willing to set up a mailing list or something if there was interest in this work. [1] The original INVITE may have resulted in two calls being setup, and no mechanism of determining the tags used is available. As well, you cannot specify which tags to use in a URI. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 11:56: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 LAA09166 for ; Wed, 29 Nov 2000 11:56:35 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F244B443C0; Wed, 29 Nov 2000 10:55:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 4EF564436E for ; Wed, 29 Nov 2000 10:54:00 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 29 Nov 2000 16:53:52 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA17500; Wed, 29 Nov 2000 17:52:22 +0100 (BST) From: "Jo Hornsby" To: "Keith Robinson" Cc: "Bertil Engelholm" , Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements Message-ID: <001001c05a24$be4e5120$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: <802569A6.005BD7C2.00@marconicomms.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, 29 Nov 2000 16:52:22 -0000 Content-Transfer-Encoding: 7bit > Is it now generally agreed that the requirement in 6.43.2 for > clients to set up the Route name-addr using Contact/From > headers (excluding maddr and port) should be removed ? This > seems to be the fundamental problem. I think so. *duck and cover* &:) - 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 Nov 29 12:01:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11203 for ; Wed, 29 Nov 2000 12:01:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A8F39443D1; Wed, 29 Nov 2000 11:00:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0FE8E443D1 for ; Wed, 29 Nov 2000 10:59:23 -0500 (EST) Received: from CINQUECENTO ([63.110.3.222]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA24909 for ; Wed, 29 Nov 2000 12:01:43 -0500 (EST) From: "Robert Sparks" To: "SIP List" Subject: RE: [SIP] Multiple-Transaction REFER Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <20001128123110.A27033@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 10:57:20 -0600 Content-Transfer-Encoding: 7bit Lets revisit the root of the time-out problem mentioned below. REFER as currently written waits until the referenced action completes before returning its final response. This runs into trouble if any of the participating UAs (including any proxies in the path of the request) decide the request has been pending too long and do whatever they do on a time-out. I've been reviewing 10.4.1 and 10.4.2 and currently I can't see where that time-out (for non-INVITE messages) is defined by the protocol. It seems to be left up to the application. 10.4.1 specifies when the request will stop being retransmitted in absence of a final response, but doesn't say when the client gives up on the request after the last retransmission. 10.4.2 even more explicitly leaves this in the applications hands: Clients using a reliable transport protocol such as TCP, SCTP or TLS do not need to retransmit requests, but MAY give up after receiving no response for an extended period of time. Perhaps we need clarification of behavior here. Would it be worth standardizing a default interpretation of Expires (using the INVITE behavior) for all requests where it doesn't have specialized meaning (like REGISTER). If we went down that path, we could also recommend behavior for how long to wait after that last retransmission. In particular, recommend extending that timeout in the face of provisional responses. There are places other than REFER where this issue will cause grief. The response to the sip-events SUBSCRIBE request might need time to obtain authorizations. Processing QAUTH in sip-for-presence may involve user interaction. Comments? RjS > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Billy Biggs > Sent: Tuesday, November 28, 2000 12:31 PM > To: Robert Sparks > Cc: SIP List > Subject: [SIP] Multiple-Transaction REFER > > > As pointed out earlier by Jonathan, the single-transaction REFER > mechanism fails as the REFER may time out. To clean things up, the > suggestion is to split up REFER into a sequence of transactions. > > To start discussion, here are some ideas: > > 1. REFER looks the same, but it is responded with a 2xx if the far end > accepts the REFER and intends to act upon it. > > 2. A REFERDONE request which signals back that the spawned INVITE > completed. Success or failure is indicated in some header (or in the > body?). This request requires a header, Refer-CSeq or similar, to > indicate which REFER transaction is being completed. > > Optionally: > > 3. A REFERSTATUS request which can signal back the call setup progress. > Requires a Refer-CSeq header. Optional support by both UAs. > > 4. A REFERCANCEL request which can attempt to cancel a pending REFER. > Requires a Refer-CSeq header. Optional support by both UAs. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 12:11:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14761 for ; Wed, 29 Nov 2000 12:11:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3896443BE; Wed, 29 Nov 2000 11:10:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 87DCF443BE for ; Wed, 29 Nov 2000 11:09:53 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 29 Nov 2000 11:09:44 -0600 (CST) From: Billy Biggs To: Alan Johnston Cc: Robert Sparks , SIP List Message-ID: <20001129110944.B28481@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] Music on Hold in ietf-sip-service-examples-00 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 11:09:44 -0600 In sip-service-examples-00, you discuss performing music on hold using REFER. A shortened call flow is below: On hold: User A User B Music Server | | | | REFER Refer-To: sip:music@server.com |<-------------| | | INVITE/200 OK/ACK | |<--------------------------->| | 200 OK | | |------------->| | | | | Off hold: | | | | REFER Refer-To: music@server.com;method=BYE |<-------------| | | BYE/200 OK | | |<--------------------------->| | 200 OK | | |------------->| | | | | I have two problems with this method: 1. In our implementation, User A will hang up the call to User B after the REFER completes successfully. This is to protect ourselves (User B will also send a BYE), however, I can imagine most implementations will be similar. 2. As mentioned in my previous email on remote device control using REFER, the URI music@server.com;method=BYE is insufficient to indicate to the UA which call should be disconnected. It's also overloading REFER and obfuscating its meaning. There are more appropriate ways to implement music on hold. One is to have User B call up the music server itself and swap the SDP (3pcc). Another is to have User A call up the music on hold server when it receives on-hold SDP. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 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 MAA18344 for ; Wed, 29 Nov 2000 12:21:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 193F3443B6; Wed, 29 Nov 2000 11:21:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 86AC644393 for ; Wed, 29 Nov 2000 11:20:11 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 29 Nov 2000 11:20:02 -0600 (CST) From: Billy Biggs To: Robert Sparks Cc: SIP List Subject: Re: [SIP] Multiple-Transaction REFER Message-ID: <20001129112002.A28604@div8.net> References: <20001128123110.A27033@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from rsparks@dynamicsoft.com on Wed, Nov 29, 2000 at 10:57:20AM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 11:20:02 -0600 Robert Sparks (rsparks@dynamicsoft.com): > I've been reviewing 10.4.1 and 10.4.2 and currently I can't see where > that time-out (for non-INVITE messages) is defined by the protocol. It > seems to be left up to the application. > > 10.4.1 specifies when the request will stop being retransmitted in > absence of a final response, but doesn't say when the client gives up > on the request after the last retransmission. If the retransmissions stop, there is no way to reliably receive the response. > Perhaps we need clarification of behavior here. Would it be worth > standardizing a default interpretation of Expires (using the INVITE > behavior) for all requests where it doesn't have specialized meaning > (like REGISTER). I like Expires how it is. For SUBSCRIBE, Expires dictates how long the subscription should last. I'm sure new extensions will have uses for Expires. In my multi-transaction proposal, an expires in the original REFER could mean the time in which it must receive a REFERDONE. This seems more clean. > There are places other than REFER where this issue will cause grief. > > The response to the sip-events SUBSCRIBE request might need time to > obtain authorizations. Processing QAUTH in sip-for-presence may > involve user interaction. I don't like having transactions outstanding for too long. The retransmission model breaks for everything except INVITE. If half a minute doesn't seem reasonable for these authorizations or user interaction, then the process must be extended to multiple transactions. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 12:31:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23177 for ; Wed, 29 Nov 2000 12:31:33 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9EAF2443E5; Wed, 29 Nov 2000 11:25:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id D35F4443E4 for ; Wed, 29 Nov 2000 11:24:26 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 29 Nov 2000 11:24:18 -0600 (CST) From: Billy Biggs To: Jo Hornsby Cc: Keith Robinson , Bertil Engelholm , Sip List Subject: Re: [SIP] RECORD-ROUTE/ROUTE requirements Message-ID: <20001129112418.B28604@div8.net> References: <802569A6.005BD7C2.00@marconicomms.com> <001001c05a24$be4e5120$4e34c3c1@ubiquity.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <001001c05a24$be4e5120$4e34c3c1@ubiquity.co.uk>; from jhornsby@ubiquity.net on Wed, Nov 29, 2000 at 04:52:22PM -0000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 11:24:18 -0600 Jo Hornsby (jhornsby@ubiquity.net): >> Is it now generally agreed that the requirement in 6.43.2 for clients >> to set up the Route name-addr using Contact/From headers (excluding >> maddr and port) should be removed ? This seems to be the fundamental >> problem. > > I think so. I think so too. That said, I have always thought that this line was a bug: "Each such proxy server adds the Request-URI of the _incoming_request_ to the beginning of the list." s/incoming request/proxy/ -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 13:53: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 NAA18834 for ; Wed, 29 Nov 2000 13:53:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 887AC4436E; Wed, 29 Nov 2000 12:53:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-201.dallas.net [209.44.42.201]) by lists.bell-labs.com (Postfix) with ESMTP id 25CB34436D for ; Wed, 29 Nov 2000 12:52:23 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id MAA18064; Wed, 29 Nov 2000 12:52:04 -0600 From: "Brian F. G. Bidulock" To: Lyndon Ong Cc: SIGTRAN@STANDARDS.NORTELNETWORKS.COM, sip@lists.bell-labs.com Message-ID: <20001129125204.F32694@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: Lyndon Ong , SIGTRAN@STANDARDS.NORTELNETWORKS.COM, sip@lists.bell-labs.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from long@POINTREYESNET.COM on Wed, Nov 29, 2000 at 10:27:07AM -0800 Subject: [SIP] SIP Dough-Boy (was: "bake-off" legal dispute) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 12:52:04 -0600 Lyndon, Was it the word "bake=off"? Or was it our occasional references to Henry as the "SIP Dough-Boy" which really got them going? ;) Lyndon Ong wrote: (Wed, 29 Nov 2000 10:27:07) > > Folks, > > For those who asked about the origin of the term "bake-off", you might > be interested in the discussion on the ietf mailing list where > apparently Pillsbury has sent a "cease and desist" letter to Henning > Schulzrinne on using the term "bake-off" for the SIP bake-offs. The > original email is dated Nov 6th. > > Are there any non-English terms that might be equivalent in meaning? > This could be a way around the Pillsbury legal team ;o) > > Cheers, > > L. Ong -- 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 Wed Nov 29 15:02: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 PAA13495 for ; Wed, 29 Nov 2000 15:02:44 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A8134435C; Wed, 29 Nov 2000 14:02:10 -0500 (EST) 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 6106D4433A for ; Wed, 29 Nov 2000 14:01:33 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G4S00501Y94XY@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 29 Nov 2000 20:00:40 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G4S004D6Y94HZ@firewall.mcit.com>; Wed, 29 Nov 2000 20:00:40 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0G4S00H01Y2QU7@pmismtp03.wcomnet.com>; Wed, 29 Nov 2000 19:56:50 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G4S00H01Y2KSU@pmismtp03.wcomnet.com>; Wed, 29 Nov 2000 19:56:49 +0000 (GMT) Received: from wcom.com ([166.46.16.150]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G4S00H2HY1VED@pmismtp03.wcomnet.com>; Wed, 29 Nov 2000 19:56:20 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 To: Billy Biggs Cc: Robert Sparks , SIP List Message-id: <3A256157.F78541B7@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <20001129110944.B28481@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 14:04:40 -0600 Content-Transfer-Encoding: 7bit Billy, So your interpretation of the REFER request is that a successful completion of the request always automatically generates a BYE request? I'd be interested to hear if other implementors have made this assumption as well. This seems to me like mixing a service with the primitive used to implement the service. I thought this was why the original name of the method was changed from TRANSFER (which is the name of a service and does imply a disconnect after successful completion) to REFER, which can be used to implement a transfer service, but just has the semantic to request establishment of a new session without affecting the existing session. Is your proposal for Music On Hold for User B to proxy media from the Music On Hold Server, or is it to send a re-INVITE to User A using SDP from the Music On Hold Server? Your other approach is for User A to choose its own Music On Hold server without assistance from User B? I'm always interested in seeing new call flows, but I'm not sure that these are better approaches. Thanks, Alan. Billy Biggs wrote: > In sip-service-examples-00, you discuss performing music on hold using > REFER. A shortened call flow is below: > > On hold: > > User A User B Music Server > | | | > | REFER Refer-To: sip:music@server.com > |<-------------| | > | INVITE/200 OK/ACK | > |<--------------------------->| > | 200 OK | | > |------------->| | > | | | > > Off hold: > > | | | > | REFER Refer-To: music@server.com;method=BYE > |<-------------| | > | BYE/200 OK | | > |<--------------------------->| > | 200 OK | | > |------------->| | > | | | > > I have two problems with this method: > > 1. In our implementation, User A will hang up the call to User B after > the REFER completes successfully. This is to protect ourselves > (User B will also send a BYE), however, I can imagine most > implementations will be similar. > > 2. As mentioned in my previous email on remote device control using > REFER, the URI music@server.com;method=BYE is insufficient to > indicate to the UA which call should be disconnected. It's also > overloading REFER and obfuscating its meaning. > > There are more appropriate ways to implement music on hold. One is to > have User B call up the music server itself and swap the SDP (3pcc). > Another is to have User A call up the music on hold server when it > receives on-hold SDP. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 16:53:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22535 for ; Wed, 29 Nov 2000 16:53:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A570F443C8; Wed, 29 Nov 2000 15:50:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id B0321443C3 for ; Wed, 29 Nov 2000 15:49:57 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 29 Nov 2000 15:49:45 -0600 (CST) From: Billy Biggs To: Alan Johnston Cc: Robert Sparks , SIP List Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 Message-ID: <20001129154945.B28840@div8.net> References: <20001129110944.B28481@div8.net> <3A256157.F78541B7@wcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A256157.F78541B7@wcom.com>; from alan.johnston@wcom.com on Wed, Nov 29, 2000 at 02:04:40PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 15:49:45 -0600 Alan Johnston (alan.johnston@wcom.com): > So your interpretation of the REFER request is that a successful > completion of the request always automatically generates a BYE > request? Implementation not interpretation. > [...] to REFER, which can be used to implement a transfer service, but > just has the semantic to request establishment of a new session > without affecting the existing session. The REFER transaction itself does not affect the old session. However, to keep our phone UI simple, we disconnect the old call. Users can't understand it otherwise. Yes, we are using REFER to implement transfer. If there are seperate requirements, such as requesting to add a user in a 3-way call, or asking the remote phone to dial another user seperately and be able to remotely control the call, then these should be seperate methods or with a Requires or something. PHONECTL was designed (and implemented) to do much of this, with an appropriate authentication structure. > Is your proposal for Music On Hold for User B to proxy media from the > Music On Hold Server, or is it to send a re-INVITE to User A using SDP > from the Music On Hold Server? Your other approach is for User A to > choose its own Music On Hold server without assistance from User B? As with most telephony features and SIP, there are many options. It is up to the implementor to pick one. My problem with your Music on Hold proposal is that it isn't interoperability-friendly. A more important problem is: >> 2. As mentioned in my previous email on remote device control using >> REFER, the URI music@server.com;method=BYE is insufficient to >> indicate to the UA which call should be disconnected. It's also >> overloading REFER and obfuscating its meaning. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 20:15: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 UAA01081 for ; Wed, 29 Nov 2000 20:15:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 08B724436C; Wed, 29 Nov 2000 19:15:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DF7644433A for ; Wed, 29 Nov 2000 19:14:14 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA03479 for ; Wed, 29 Nov 2000 20:14:05 -0500 (EST) Message-ID: <3A25A9DD.2D80D137@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] New IANA header registry now online Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 20:14:05 -0500 Content-Transfer-Encoding: 7bit http://www.isi.edu/in-notes/iana/assignments/sip-parameters Please send any corrections to me for the time being. -- 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 Nov 29 22: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 WAA06179 for ; Wed, 29 Nov 2000 22:08:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0F7344367; Wed, 29 Nov 2000 21:08:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from localhost.localdomain (unknown [63.110.3.2]) by lists.bell-labs.com (Postfix) with ESMTP id D3DD94433A for ; Wed, 29 Nov 2000 21:07:32 -0500 (EST) Received: from cowboys (IDENT:root@dyn-tx-app-004 [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id WAA07045 for ; Wed, 29 Nov 2000 22:08:27 -0600 Message-ID: <005401c05a7a$6434b660$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" 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 Subject: [SIP] WG Last Call for draft-ietf-sip-guidelines-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 29 Nov 2000 21:05:26 -0600 Content-Transfer-Encoding: 7bit I thought I had done this a few weeks ago, but the email seems to have not happened. My apologies. I hereby issue a WG last call on Jonathan's informational-track "Guidelines to the Authors of SIP Extensions", closing December 24, 2000. My apologies on the overlap with our December meeting, but the document has been around for many months without further comment and I should have closed it sooner. The document can be retrieved from: http://search.ietf.org/internet-drafts/draft-ietf-sip-guidelines-00.txt -- Dean Willis _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Nov 29 22:29:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13645 for ; Wed, 29 Nov 2000 22:29:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5738244393; Wed, 29 Nov 2000 21:29:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1C57B4433A for ; Wed, 29 Nov 2000 21:28:22 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA00550; Wed, 29 Nov 2000 22:30:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 22:26:06 -0500 Message-ID: From: Jonathan Rosenberg To: "'Dean Willis'" , "IETF SIP (E-mail)" Subject: RE: [SIP] WG Last Call for draft-ietf-sip-guidelines-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 29 Nov 2000 22:26:05 -0500 A few corrections here; I submitted a -01 which should appear shortly. In the mean time: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-sip-guidelines-01.txt Secondly, I believe this is more appropriate as a BCP. The "guidelines for authors of RTP payload formats", which is a similar document, is a BCP. -Jonathan R. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, November 29, 2000 10:05 PM > To: IETF SIP (E-mail) > Subject: [SIP] WG Last Call for draft-ietf-sip-guidelines-00.txt > > > I thought I had done this a few weeks ago, but the email > seems to have not > happened. My apologies. > > I hereby issue a WG last call on Jonathan's > informational-track "Guidelines > to the Authors of SIP Extensions", closing December 24, 2000. > My apologies > on the overlap with our December meeting, but the document > has been around > for many months without further comment and I should have > closed it sooner. > > The document can be retrieved from: > > http://search.ietf.org/internet-drafts/draft-ietf-sip-guidelin > es-00.txt > > -- > Dean Willis > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 00:26: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 AAA29156 for ; Thu, 30 Nov 2000 00:26:36 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C49A44362; Wed, 29 Nov 2000 23:26:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5333C4433A for ; Wed, 29 Nov 2000 23:25:07 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00903; Thu, 30 Nov 2000 00:27:20 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 00:22:55 -0500 Message-ID: From: Jonathan Rosenberg To: "'Howard Hart'" , "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 00:22:54 -0500 I think this all has to be taken within the context that the entfw draft is NOT meant to be a long term solution. It is a short term hack, nothing more. As such, I am not really worried about potential HTTPS caching proxies (if even possible) that might arise one or two years from now. The draft aims really to solve a chicken-and-egg problem. No enterprise IT admin is going to let SIP (let alone UDP based RTP) in or out of the firewall until there is overwhelming demand and strong reasons for them to do so. These incentives come when enough internal users are using services and deriving business value from them. Unfortunately, that won't ever happen since the firewalls block SIP/RTP. So you see the problem. Through what is, in the best case, an ugly hack, we can get some usage going within enterprises, and then the demand can grow, and then IT departments will change policies so that users can stop doing horrible things like port 443 tunneling, and rather use SIP the original way it was designed to be used. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Howard Hart [mailto:hch@ipdialog.com] > Sent: Tuesday, November 28, 2000 3:09 PM > To: Henning G. Schulzrinne > Cc: Jonathan Rosenberg; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt > > > Hi Henning, > > See responses below: > > "Henning G. Schulzrinne" wrote: > > > Howard Hart wrote: > > > > > > Jonathan and Henning, > > > > > > I think this is a great shot at tunneling SIP and RTP > through Firewalls, > > > though you may want to add the following caveats to section 6: > > > > > > 1) Wrt corporate tunneling, high-bandwidth voice > traffic has a distinct > > > network signature vs. (relatively) low-bandwidth Web > traffic. If you blast > > > voice traffic, encrypted or unencrypted over Web ports, > it's going to stick out > > > like a sore thumb even using the crudest network > monitoring tools. ISS and the > > > other network intrusion detection packages may even flag > it as a Netbus, > > > BackOrifice, or Distributed Denial of Service attack > signature. Most network > > > administrators will shut the originating host/port down > immediately and ask > > > questions later. > > > > I'm not sure whether that's a problem, as voice bandwidth > is generally > > much lower than web retrievals. (As low as 8 kb/s vs. a few hundred > > kilo*bytes*/second on my desktop to many web servers. If I > download a > > piece of software, it will easily consume as much bandwidth > as a phone > > call: 3 minute call = 180 seconds = 180 kBytes, which is > smaller than > > many individual web pages.) > > If the average Web page retrieval required 100+ > kbytes/second, I don't think the > average user on their 28.8 baud, 3-5 kbytes/second (w/VJ > compression) modem would do > much web surfing :-), but I get your point. My contention is > divergence from Web > traffic signatures will be highly dependent on a number of > cumulative factors, from > your locally provisioned bandwidth, to your usage patterns, > to the number of times > you access the same server, to the sensitivity of your > intrusion detection package, > to how long you stay on the phone, etc. If you throw in > sustained, encrypted RTP > packet rate signatures at 25-50 pps over several minutes with > the added burden that > only a small percentage of Web traffic is encrypted/port 443, > it will probably > trigger the alarms, but your mileage will vary depending on > the level of paranoia at > your local site. > > > > > > > > > > > 2) The Internet backbone itself has been heavily > optimized (some might say > > > almost too optimized) for port 80 traffic, and is moving > in that direction (as > > > > This is bogus, except for the web caching that some ISPs (but, > > fortunately, by no means all ISPs) do. Routers don't know > about port 80. > > Agreed, my wording was poor. More accurately, ISPs are > deploying web caching engines > at their edges to eliminate/optimize redundant HTTP/port 80 > traffic over their > backbones, especially when they're being used for transit vs. > direct access to Web > servers within their networks. > > > > > > > > much as is feasible) for port 443/HTTPS. Increasingly, > ISPs are using Web > > > caching engines to limit this traffic across their > backbones. Case in point--I > > > used Checkpoint's encrypted VPN product in a previous > company to connect an > > > overseas location to our site (encrypted payloads, port > numbers stay the same). > > > Our remote site wanted to access our internal Web server. > Unfortunately, one of > > > the intermediate ISPs was using a Web caching product, > which resulted in the > > > caching engine intercepting, then attempting to originate > an (unauthorized) > > > port 80 access to our internal Web server on the remote > end's behalf, with the > > > expected (non)result. The answer from the ISP was, of > course, "well it works > > > fine for all our normal customers--EOM". I think you'd > see some very > > > interesting side effects if you applied a tunneled RTP > stream to this or other > > > kinds of caching servers on port 80. > > > Granted, 443/SSL-caching is a much more difficult > problem, equating to a > > > man-in-the- middle attack--maybe even unsolvable, but > given the monetary > > > inceptive is huge to come up with a solution here too, > partial or otherwise.... > > > > Much of 443 traffic is inherently uncacheable, as it is for > things like > > forms responses from web orders. I doubt that even the looniest ISP > > would want to return your airline booking confirmation page or bank > > balance to me. Also, unless the cache has the certificate > of the origin > > server, intercept is just not possible. I doubt that Citibank, say, > > would hand out their private key to random ISPs. > > True, and as I stated above, maybe unsolvable, but for a > sample of where pieces of > this might come into play later on, check out > http://www.f5.com/f5products/bigip/ecommerce, one of the more > popular Web > load-balancers. The advantage here is you offload encryption > and key negotiation > from individual servers in a large server farm and place the > burden in hardware on > the load-balancer. The question then becomes an ISP/SysAdmin > policy issue as to > whether you can locate your remote tunneling Proxy in front > of or behind the > load-balancer, and what's the impact when the load-balancer > assumes all traffic on > port 443 is HTTP only. > > NOTE: This is obviously NOT an issue for your scheme today. > Just something to > consider or maybe even take advantage of in the future. > > 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 Thu Nov 30 00:28: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 AAA29870 for ; Thu, 30 Nov 2000 00:28:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 555E5443CC; Wed, 29 Nov 2000 23:28:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BBF89443CC for ; Wed, 29 Nov 2000 23:27:30 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00911; Thu, 30 Nov 2000 00:29:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 00:25:25 -0500 Message-ID: From: Jonathan Rosenberg To: "'sunayak@hss.hns.com'" , sip@lists.bell-labs.com Subject: RE: [SIP] Multiple SDP bodies in a SIP message MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 00:25:23 -0500 Multiple SDP is not used within SIP. Whilst its not explicitly prohibited, the rfc implicitly discusses a single SDP payload and describes usage only for this case. I'll add a note saying just one SDP. -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: sunayak@hss.hns.com [mailto:sunayak@hss.hns.com] > Sent: Monday, November 27, 2000 11:48 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Multiple SDP bodies in a SIP message > > > > > Hi All ! > I had a query regarding SDP message bodies. > > Is it possible to have multiple SDP bodies in a single SIP > message. If so, > where would this be applicable ? (Could someone give a > scenario/example) > Eg: > > > > ... > ... > > > Thanks in advance > Subhash Nayak > Hughes Software Systems > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 30 00: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 AAA03988 for ; Thu, 30 Nov 2000 00:37:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5020443DE; Wed, 29 Nov 2000 23:37:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D348244391 for ; Wed, 29 Nov 2000 23:36:51 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00948; Thu, 30 Nov 2000 00:39:09 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 00:34:44 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , Alan Johnston Cc: Robert Sparks , SIP List Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 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, 30 Nov 2000 00:34:44 -0500 > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Wednesday, November 29, 2000 4:50 PM > To: Alan Johnston > Cc: Robert Sparks; SIP List > Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 > > > Alan Johnston (alan.johnston@wcom.com): > > > So your interpretation of the REFER request is that a successful > > completion of the request always automatically generates a BYE > > request? > > Implementation not interpretation. > > > [...] to REFER, which can be used to implement a transfer > service, but > > just has the semantic to request establishment of a new session > > without affecting the existing session. > > The REFER transaction itself does not affect the old session. > However, to keep our phone UI simple, we disconnect the old > call. Users > can't understand it otherwise. You are most definitely confusing a primitive operation (REFER), with a specific service, which is transfer. As Alan correctly pointed out, REFER has other applications beyyond transfer. Assuming that everytime the device sends a REFER, its a transfer, is both an incorrect interpretation and an incorrect implementation. Now, it may be that when a user presses "transfer" on your phone, it sends a REFER then a BYE. Thats fine; in this flow here, the user would not press "transfer", since this is not a transfer service. > > Yes, we are using REFER to implement transfer. If there > are seperate > requirements, such as requesting to add a user in a 3-way call, or > asking the remote phone to dial another user seperately and be able to > remotely control the call, then these should be seperate > methods or with > a Requires or something. PHONECTL was designed (and > implemented) to do > much of this, with an appropriate authentication structure. Absolutely not. Putting a Require header in to specify each service for which REFER might be used is a bad thing. Its the same as writing a formal protocol spec for each specific service. Our aim here was to build primitive operation which could be used to build many services, without every party knowing the service. Just the invoker needs to know how to map the services into protocol primitives. -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 Nov 30 01:06:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16540 for ; Thu, 30 Nov 2000 01:06:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A85B44391; Thu, 30 Nov 2000 00:06:10 -0500 (EST) 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 8E02B4433A for ; Thu, 30 Nov 2000 00:05:57 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id MAA20858; Thu, 30 Nov 2000 12:11:16 -0600 Message-ID: <007101c05a93$500bb210$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "Jonathan Rosenberg" , "IETF SIP (E-mail)" References: Subject: Re: [SIP] WG Last Call for draft-ietf-sip-guidelines-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 00:01:46 -0600 Content-Transfer-Encoding: 7bit Thanks. I stand corrected (actually, I sit asleep and typing) The working group last call is on the -01 version of the draft, which can be retrieved from: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-guidelines-01.txt This document is intended for publication as a BCP. Good night. -- Dean Willis ----- Original Message ----- From: "Jonathan Rosenberg" To: "'Dean Willis'" ; "IETF SIP (E-mail)" Sent: Wednesday, November 29, 2000 9:26 PM Subject: RE: [SIP] WG Last Call for draft-ietf-sip-guidelines-00.txt > A few corrections here; I submitted a -01 which should appear shortly. In > the mean time: > http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-sip-guidelines-01.txt > > Secondly, I believe this is more appropriate as a BCP. The "guidelines for > authors of RTP payload formats", which is a similar document, is a BCP. > > -Jonathan R. > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Wednesday, November 29, 2000 10:05 PM > > To: IETF SIP (E-mail) > > Subject: [SIP] WG Last Call for draft-ietf-sip-guidelines-00.txt > > > > > > I thought I had done this a few weeks ago, but the email > > seems to have not > > happened. My apologies. > > > > I hereby issue a WG last call on Jonathan's > > informational-track "Guidelines > > to the Authors of SIP Extensions", closing December 24, 2000. > > My apologies > > on the overlap with our December meeting, but the document > > has been around > > for many months without further comment and I should have > > closed it sooner. > > > > The document can be retrieved from: > > > > http://search.ietf.org/internet-drafts/draft-ietf-sip-guidelin > > es-00.txt > > > > -- > > Dean Willis > > > > > > > > _______________________________________________ > > 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 Thu Nov 30 01:08: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 BAA17992 for ; Thu, 30 Nov 2000 01:08:50 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B78E8443F2; Thu, 30 Nov 2000 00:07:12 -0500 (EST) 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 1909C4433A for ; Thu, 30 Nov 2000 00:06:06 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id MAA20855; Thu, 30 Nov 2000 12:11:15 -0600 Message-ID: <007001c05a93$4fd18f40$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" Cc: "Joerg Ott (E-mail)" , "Brian Rosen (E-mail)" , "Jonathan Rosenberg (E-mail)" , "Henning Schulzrinne (E-mail)" 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 Subject: [SIP] WG Last Call on Caller Preferences Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 29 Nov 2000 23:48:37 -0600 Content-Transfer-Encoding: 7bit Well, it looks like I let another draft get a little long iin the tooth without care and feeding. There has been no discussion for several months, and all threads appear to have been successfully answered on the list. I am therefore issuing a WG last call on the Caller Preferences draft, retrievable from: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-02.txt This last call will close December 24. I want to send this puppy to the IESG for New Years. -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 01:11: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 BAA19600 for ; Thu, 30 Nov 2000 01:11:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B8E2443E7; Thu, 30 Nov 2000 00:10:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0E0BD443E7 for ; Thu, 30 Nov 2000 00:09:23 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01104; Thu, 30 Nov 2000 01:11:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 01:07:17 -0500 Message-ID: From: Jonathan Rosenberg To: "'Dean Willis'" , "IETF SIP (E-mail)" Cc: "Joerg Ott (E-mail)" , "Brian Rosen (E-mail)" , Jonathan Rosenberg , "Henning Schulzrinne (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] RE: WG Last Call on Caller Preferences Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 30 Nov 2000 01:07:17 -0500 Once again, I must unfortunately correct our over-zealous working group chair. There is an updated version of this document in the I-D editor pipe. Until it appears, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-sip-callerprefs-03.txt Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, November 30, 2000 12:49 AM > To: IETF SIP (E-mail) > Cc: Joerg Ott (E-mail); Brian Rosen (E-mail); Jonathan Rosenberg > (E-mail); Henning Schulzrinne (E-mail) > Subject: WG Last Call on Caller Preferences > > > Well, it looks like I let another draft get a little long iin > the tooth > without care and feeding. There has been no discussion for > several months, > and all threads appear to have been successfully answered on > the list. I am > therefore issuing a WG last call on the Caller Preferences draft, > retrievable from: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-02.txt > > This last call will close December 24. I want to send this > puppy to the IESG > for New Years. > > -- > Dean > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 01:15:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21684 for ; Thu, 30 Nov 2000 01:15:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B19F443F0; Thu, 30 Nov 2000 00:15:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id A805C443F0 for ; Thu, 30 Nov 2000 00:14:46 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 30 Nov 2000 00:14:36 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Alan Johnston , Robert Sparks , SIP List Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 Message-ID: <20001130001436.A29311@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from jdrosen@dynamicsoft.com on Thu, Nov 30, 2000 at 12:34:44AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 00:14:36 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): >> The REFER transaction itself does not affect the old session. >> However, to keep our phone UI simple, we disconnect the old call. >> Users can't understand it otherwise. > > You are most definitely confusing a primitive operation (REFER), with > a specific service, which is transfer. Understandably we need some primitive. I think we agree this primitive is "initiate a session with the Refer-To address". Due to the design constraints of our device, we cannot keep around both calls. I suspect that a PSTN gateway would be in a similar situation, since there is no way for the POTS phone to be able to indicate this. When the new session is active, we disconnect the old. Yes, we are unable to use services which require the old call to stay active. It's a constraint. But our implementation is completely reasonable and we do follow the spec. So far, the only service I've halted seems to be Music-On-Hold, which requires that the far end have some crazy logic to send a BYE based on a REFER anyways. I'm sure there will be other services that this device won't be able to handle, but I'm not worried yet. I suspect that other SIP devices which try to act like phones will behave similarily, which is why I suggested to change the music call flow to be more interoperability-friendly. > [...] Putting a Require header in to specify each service for which > REFER might be used is a bad thing. Its the same as writing a formal > protocol spec for each specific service. Our aim here was to build > primitive operation which could be used to build many services, > without every party knowing the service. Just the invoker needs to > know how to map the services into protocol primitives. Yes, but there are two actors here. The sender of the REFER (who knows the service it wants to provide) and the receiver of the REFER (who doesn't). At least in this example, if we knew that the sender really needed the call to stay up after the REFER completes, then we could at least reject the REFER. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 01:21: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 BAA24754 for ; Thu, 30 Nov 2000 01:21:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE69E443FC; Thu, 30 Nov 2000 00:21:09 -0500 (EST) 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 467334433A for ; Thu, 30 Nov 2000 00:20:30 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id MAA20967; Thu, 30 Nov 2000 12:25:49 -0600 Message-ID: <002201c05a95$587f0440$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "Jonathan Rosenberg" , "IETF SIP (E-mail)" Cc: "Joerg Ott (E-mail)" , "Brian Rosen (E-mail)" , "Jonathan Rosenberg" , "Henning Schulzrinne (E-mail)" References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Re: WG Last Call on Caller Preferences Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 30 Nov 2000 00:15:37 -0600 Content-Transfer-Encoding: 7bit Yes indeed, I am underslept and continue to be amazed by colleaugue Jonathan's forebearance. The correct document for WG last call ending 24Dec is http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-callerprefs-03.txt -- Dean ----- Original Message ----- From: "Jonathan Rosenberg" To: "'Dean Willis'" ; "IETF SIP (E-mail)" Cc: "Joerg Ott (E-mail)" ; "Brian Rosen (E-mail)" ; "Jonathan Rosenberg" ; "Henning Schulzrinne (E-mail)" Sent: Thursday, November 30, 2000 12:07 AM Subject: RE: WG Last Call on Caller Preferences > Once again, I must unfortunately correct our over-zealous working group > chair. > > There is an updated version of this document in the I-D editor pipe. Until > it appears, you can pick up a copy at: > > http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-sip-callerprefs-03.txt > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Thursday, November 30, 2000 12:49 AM > > To: IETF SIP (E-mail) > > Cc: Joerg Ott (E-mail); Brian Rosen (E-mail); Jonathan Rosenberg > > (E-mail); Henning Schulzrinne (E-mail) > > Subject: WG Last Call on Caller Preferences > > > > > > Well, it looks like I let another draft get a little long iin > > the tooth > > without care and feeding. There has been no discussion for > > several months, > > and all threads appear to have been successfully answered on > > the list. I am > > therefore issuing a WG last call on the Caller Preferences draft, > > retrievable from: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-02.txt > > > > This last call will close December 24. I want to send this > > puppy to the IESG > > for New Years. > > > > -- > > Dean > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 01:31: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 BAA00184 for ; Thu, 30 Nov 2000 01:31:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1840E44401; Thu, 30 Nov 2000 00:29:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 0E1E04433A for ; Thu, 30 Nov 2000 00:28:19 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 22:27:54 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , Bertil Engelholm , SIP@lists.bell-labs.com Cc: Jonathan Rosenberg Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 29 Nov 2000 22:27:53 -0800 Comments below. > > > This discussion seems endless 8-). > > Indeed. And there I was hoping that we would have this > sorted for the Bake-Off. Oh well. > I still think we can have a proposal before the bake-off [and unfotunately I can't make the bake-off]. At least that gives a starting point. > > The main purpose with RECORD-ROUTE/ROUTE as I > > understand it is that a server can make shure it will > > get all new requests for a certain call-leg by adding > > a RECORD-ROUTE to the first (and consequtive) request. > > Exactly. And that is why I think we should mandate (i.e., > MUST) that it is a SIP URL with either no transport > parameter, or a transport parameter that matches /UDP/i. > If these conditions are not met, then we cannot guarantee > that a client will be able to route successfully. > > As an analogy, consider the fact that UDP is a MUST. > I wouldn't be surprised if someone writes something that > doesn't do UDP, because TLS is essential (for some reason). > Now they can't expect to be able to interoperate, but > doubtless that won't matter, since the parameters of > the network this non-UDP-supporting-something is going > to be running in will ensure that it can interoperate > with whatever it needs to. > > In the same way, someone might one day insert a non-SIP > URI into a Record-Route, but they can't expect it to > work unless they know that the devices in the network > are controlled such that they'll understand this non-SIP > URI. > Yes! yes! yes! I agree entirely. > > The next issue I see is port number. Today you have > > to use the same port number from both caller and callee > > because the same ROUTE is used in both directions. > > Should it be possible to use different port numbers ? > > I would say yes to this. If a server wants to have > > different port numbers it should have the possibility > > to do so. > > Well, if a proxy is prepared to modify the Record-Route > in the response, then it is free to expose a different > port to callee/caller. > Right, its all up to the proxy as to what it puts in there. We just have to say what is the minimum that it should put in there. > > The more controversial parts I guess is the address > > and the transport. Should they be RECORD-ROUTE/ROUTE > > parameters or URI parameters ? Personally I prefere > > RECORD-ROUTE/ROUTE parameters because that means I > > don't have to look inside the ROUTE-URI and that makes > > me more future proof towards possibly new types of URIs. > > > > The other possibility that has been discussed is to > > only allow SIP-URL as URI in ROUTE and put the address > > in there as today (maddr). I don't like this solution > > because if a new type of URI pops up in the future that > > a server needs to put in as identification it can't do > > it directly. Instead it has to convert it into a SIP-URL > > in some way. > > If a proxy needs to embed exotic URIs (or whatever) in > Record-Route, then I think it should have to suffer all > the pain involved. > > If we use anything other than UDP SIP URLs, I can't see > how we can guarantee interoperability. > Exactly. I think this is more a matter of confusion than controversy. Bertil said: > > The more controversial parts I guess is the address > > and the transport. So a SIP URL is adquate for all host based networks and UDP transport is required - so why make life hard. Just because _the original_ call routing is done on mailto, tel or whatever esoteric URI scheme doesn't impact the fact that a Route header MUST be sent to the specified UDP reachable host. As you say Jo, if someone wants to use non-SIP Route URL's that's fine but you can't guarantee interoperability so it should not be put in the SIP spec. Ok so as I see it: -Record-Route headers must be SIP URL's. -The address in the SIP URL must be the UDP reachable address of the proxy inserting the route. -The username and any parameters added to the URL to the header are implementation defined. -The Record-Route should use angle brackets. Ie, Record-Route: ;zzzzz=zzzzz where y are the implementation defined Record-Route URL parameters and zzzz are the implementation defined Record-Route header parameters. xxxxx may be empty. -If multiple Record-Routes are added for the same request (ie, spiral route), then each Record-Route added SHOULD be different so that they can be distinguished. -In the response to a Record-Route'd request, a proxy MAY change any Record-Route header that the it originally generated. - A UAS must copy the Record-Route unchanged into the Route header; a UAC must copy the Record-Route unchanged into the Route header, reversing the order. A Route header is added if a Contact is added (as before). - If a proxy inserts Record-Route header into a request without Contact or Record-Route headers, then the Proxy SHOULD insert a Contact into the request with the From URL information and a maddr of the source address. [This ia KISS option. Contacts are now mandatory and so this is only required for supporting older UA's and why don't we keep the proxy behaviour as simple as possible. Can anyone see any reasons why this would cause problems?] - If a proxy receives a response to a request in which it added a Record-Route header AND the request does not contain a COntact header AND no new headers have been added by other proxies (ie is last Record-Route), then the proxy SHOULD add a Contact header field to the response with the original Request-URI and an additional maddr parameter with the forward address (to replicate the original routing action). [This ia KISS option. Contacts are now mandatory and so this is only required for supporting older UA's and why don't we keep the proxy behaviour as simple as possible (please!!). Can anyone see any reasons why this would cause problems?] In my mind, this allows the proxy the most freedom of how much information is placed in the Record-Route and how to encode it. The backwards compat case where there is no Contact added is handled in the simplest way possible that should give a good chance of success. Jonathan, do you still want to argue for more stringent restrictions that the username cannot be empty and that the proxy MUST change the Record-Route in the response ? Comments or omissions? Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 03:09: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 DAA00262 for ; Thu, 30 Nov 2000 03:09:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 45A1744377; Thu, 30 Nov 2000 02:09:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id F0CC144371 for ; Thu, 30 Nov 2000 02:08:10 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA01493 for ; Thu, 30 Nov 2000 03:10:32 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 03:06:06 -0500 Message-ID: From: Jonathan Rosenberg 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] as if there wasn't enough traffic on this darn list... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 03:06:05 -0500 So, figuring we didn't all have enough email on the sip list to read (I am personally hopelessly behind), let me stir things around some more with another proposal for something to ditch from the spec. Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You can send nothing in the INVITE, followed by SDP in the 200, and then SDP in ACK (and fortunately I don't know anyone who actively does this). Or, you can send SDP in INVITE, SDP in 200, and nothing in ACK. I also think there are several confused implementations that likely send it in all three. Add to this the unfortunate PRACK mess, which also has been used to send SDP in order to support the manyfolks resource work when used with 3pcc, but which is yet unimplemented. It all adds up to a messy confusion. Its not clear what it means to send SDP in all these places, and how it works. So, my proposal is that we simplify. We only allow SDP in INVITE and then provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds like a Dr. Seuss rhyme, doesn't it?) The latest 3pcc draft no longer recommends using the SDP-in-ACK, since it has problems. Given that there don't seem to be useful applications of it any longer, and given that, to my knowledge, it is not sent by anyone (at least not in any commercially shipping boxes, I hope), I'd like to yank it. There is a consequence, and that is dealing with the manyfolks requirement for sending an updated SDP to deal with manyfolks+3pcc. My proposal for that is to use a re-invite, rahter than PRACK, to carry the updated SDP. This does mean that we need to allow, in SIP, a re-INVITE to arrive while an initial INVITE is in progress. Allowing this would also address some of the concerns raised in previous threads about handling requirements for changes in early media. I don't think its hard to deal with the re-INVITE while INVITE-is-active case. The simplest solution is to reject the first INVITE and continue processing with the second one, using the new SDP and all. Anyway, before getting into those details, what does the group think about dropping the SDP-in-ACK and SDP-in-PRACK stuff? -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 Nov 30 03:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08341 for ; Thu, 30 Nov 2000 03:29:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE379443B7; Thu, 30 Nov 2000 02:29:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id D847744371 for ; Thu, 30 Nov 2000 02:28:19 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eAU8TY506062; Thu, 30 Nov 2000 13:59:35 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eAU8b8k08560; Thu, 30 Nov 2000 14:07:13 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569A7.002EC714 ; Thu, 30 Nov 2000 14:00:56 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: "'sip@lists.bell-labs.com'" Message-ID: <652569A7.002EC67C.00@sampark.hss.hns.com> Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 14:00:53 +0530 SDP in PRACK I have no problems with. However ,removing SDP in ACK will break some SIP-H.323 implementations which send media on ACK. There were two approaches to this, one of which was SDP in ACK. So those who took this latter approach will suffer (although I dont know how many commercial deployments exists - I guess for most it would just be another evening or two of re-working in their labs) As far as receiving multiple INVITE before each trans. end is concerned, at first thought this seems messier for the developer. All this while , if you received T2 while T1 was in progress (T=Transaction) from the same endpoint, you could send a bad message with a retry after. This made implementations simple, but now with multipe INVITEs, the receiving side has to remember: * CSeq values of all INVITEs and respond with app. 200 OKs * remember possible diff. media parameters for each recvd. INVITE and respond with OK * know how to correlate an ACK recvd afer it sends back Ok for one of the overlapped invites. All this can be surely implemented, but at first thought, it looks dirty. Agreed though that it solves some problems of efficiency (eg overlapped dialing). This entire thread of record-route reworking along with now multiple INVITEs before they complete seem to be slowly making life that much more difficult :-) Thoughts ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jonathan Rosenberg on 11/30/2000 01:36:05 PM To: "'sip@lists.bell-labs.com'" cc: Subject: [SIP] as if there wasn't enough traffic on this darn list... So, figuring we didn't all have enough email on the sip list to read (I am personally hopelessly behind), let me stir things around some more with another proposal for something to ditch from the spec. Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You can send nothing in the INVITE, followed by SDP in the 200, and then SDP in ACK (and fortunately I don't know anyone who actively does this). Or, you can send SDP in INVITE, SDP in 200, and nothing in ACK. I also think there are several confused implementations that likely send it in all three. Add to this the unfortunate PRACK mess, which also has been used to send SDP in order to support the manyfolks resource work when used with 3pcc, but which is yet unimplemented. It all adds up to a messy confusion. Its not clear what it means to send SDP in all these places, and how it works. So, my proposal is that we simplify. We only allow SDP in INVITE and then provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds like a Dr. Seuss rhyme, doesn't it?) The latest 3pcc draft no longer recommends using the SDP-in-ACK, since it has problems. Given that there don't seem to be useful applications of it any longer, and given that, to my knowledge, it is not sent by anyone (at least not in any commercially shipping boxes, I hope), I'd like to yank it. There is a consequence, and that is dealing with the manyfolks requirement for sending an updated SDP to deal with manyfolks+3pcc. My proposal for that is to use a re-invite, rahter than PRACK, to carry the updated SDP. This does mean that we need to allow, in SIP, a re-INVITE to arrive while an initial INVITE is in progress. Allowing this would also address some of the concerns raised in previous threads about handling requirements for changes in early media. I don't think its hard to deal with the re-INVITE while INVITE-is-active case. The simplest solution is to reject the first INVITE and continue processing with the second one, using the new SDP and all. Anyway, before getting into those details, what does the group think about dropping the SDP-in-ACK and SDP-in-PRACK stuff? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 05:37: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 FAA20498 for ; Thu, 30 Nov 2000 05:37:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F44E44371; Thu, 30 Nov 2000 04:37:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id E735E44357 for ; Thu, 30 Nov 2000 04:36:28 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 30 Nov 2000 10:36:21 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA08196; Thu, 30 Nov 2000 11:34:52 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , "Bertil Engelholm" , Cc: "Jonathan Rosenberg" Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements Message-ID: <000701c05ab9$2be4fa10$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: Thu, 30 Nov 2000 10:34:51 -0000 Content-Transfer-Encoding: 7bit Robert wrote: > So a SIP URL is adquate for all host based networks and UDP > transport is required - so why make life hard. Just because > _the original_ call routing is done on mailto, tel or whatever > esoteric URI scheme doesn't impact the fact that a Route > header MUST be sent to the specified UDP reachable host. Very much so. > As you say Jo, if someone wants to use non-SIP Route URL's > that's fine but you can't guarantee interoperability so it > should not be put in the SIP spec. Indeed. > Ok so as I see it: > > -Record-Route headers must be SIP URL's. > -The address in the SIP URL must be the UDP reachable address > of the proxy inserting the route. > -The username and any parameters added to the URL to the header > are implementation defined. > -The Record-Route should use angle brackets. > Ie, Record-Route: ;zzzzz=zzzzz > where y are the implementation defined Record-Route URL > parameters and zzzz are the implementation defined Record-Route > header parameters. xxxxx may be empty. (as may be yyyyy / zzzzz) > -If multiple Record-Routes are added for the same request > (ie, spiral route), then each Record-Route added SHOULD be > different so that they can be distinguished. > -In the response to a Record-Route'd request, a proxy MAY > change any Record-Route header that the it originally > generated. > - A UAS must copy the Record-Route unchanged into the Route > header; a UAC must copy the Record-Route unchanged into the > Route header, reversing the order. A Route header is added > if a Contact is added (as before). No arguments here. &:) > - If a proxy inserts Record-Route header into a request > without Contact or Record-Route headers, then the Proxy SHOULD > insert a Contact into the request with the From URL information > and a maddr of the source address. [This ia KISS option. > Contacts are now mandatory and so this is only required for > supporting older UA's and why don't we keep the proxy behaviour > as simple as possible. Can anyone see any reasons why this > would cause problems?] > - If a proxy receives a response to a request in which it > added a Record-Route header AND the request does not contain > a COntact header AND no new headers have been added by other > proxies (ie is last Record-Route), then the proxy SHOULD add > a Contact header field to the response with the original > Request-URI and an additional maddr parameter with the forward > address (to replicate the original routing action). > [This ia KISS option. Contacts are now mandatory and so this > is only required for supporting older UA's and why don't we > keep the proxy behaviour as simple as possible (please!!). > Can anyone see any reasons why this would cause problems?] I don't think that proxies should start second-guessing UAS. I would say that the simplest thing is just to say that when the UA is building the Route header list, it should append the Contact, if present; failing that, the From. Really old UAs might lose, but they were always going to do that, anyway[0]. Cheers, - Jo. [0] I'm obviously a bis snob. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 07:32:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10814 for ; Thu, 30 Nov 2000 07:32:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B33E4437B; Thu, 30 Nov 2000 06:32:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 83CEB44357 for ; Thu, 30 Nov 2000 06:31:59 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 30 Nov 2000 12:31:51 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA16881; Thu, 30 Nov 2000 13:30:27 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Sip Mail List X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00113012320203.20477@gethin> Content-Transfer-Encoding: 8bit Subject: [SIP] 3PCC and the re-invite response Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 12:19:19 +0000 Content-Transfer-Encoding: 8bit people, i'm slightly concerened (maybe un-justifably) about the re-invite working of the 3PCC draft. my concern is that it is possible (is it not?) for the user agent receiving the re-invite to change its SDP settings in its response as follows: A Controller B | INV held SDP | | |<------------------| | | | | | 200 SDP A1 | | |-----------------> | INV SDP A1 | | ACK |----------------->| |<----------------- | | | | 200 SDP B1 | | |<-----------------| | | | | | ACK | | INV SDP B1 |----------------->| |<------------------| | | 200 OK SDP A2 | | |------------------>| | | ACK | | |<------------------| | | | | BROKEN RTP | | | | | | | NOTE: A has returned different SDP in its two different 200 OK messages. Why might it do this? It might not but it is possible is it not. perhaps we should mandate that an agent can only change its SDP for a session in an INVITE not in a response (after the initial INVITE/RESPONSE exchange of course) what do we think? -- 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 Thu Nov 30 07:37: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 HAA12468 for ; Thu, 30 Nov 2000 07:37:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F6094439B; Thu, 30 Nov 2000 06:37:10 -0500 (EST) 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 B92DD44357 for ; Thu, 30 Nov 2000 06:36:17 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id eAUCa9G11380 for ; Thu, 30 Nov 2000 13:36:09 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Nov 30 13:36:08 2000 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 30 Nov 2000 13:36:07 +0100 Message-ID: <56E7307B0850D411B1480008C75DD5EAB73E3F@enlrynt303.dsn.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "'Jonathan Rosenberg'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] as if there wasn't enough traffic on this darn list... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 13:36:06 +0100 Hello Jonathan, Hmm yes,it is a good idea to keep things clear. I agree that it is a good idea to keep the ACK free of SDP and if you want to change the session, then to send a re-invite. Another advantage is that in this case, the UAs can already act on the 200 OK SDP message without waiting for the ACK. (saves some time). cheers Arnoud _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk ABACUS Lab Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 09:34: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 JAA29390 for ; Thu, 30 Nov 2000 09:34:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E385443C7; Thu, 30 Nov 2000 08:34:10 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 3CB5E44357 for ; Thu, 30 Nov 2000 08:33:02 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Nov 30 09:30:38 EST 2000 Received: by lists.bell-labs.com (Postfix) id ECA8344380; Thu, 30 Nov 2000 09:18:20 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 001954437D for ; Thu, 30 Nov 2000 09:18:17 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA11917; Thu, 30 Nov 2000 08:18:15 -0600 Cc: "'sip@lists.bell-labs.com'" Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA11907; Thu, 30 Nov 2000 08:18:13 -0600 Message-ID: <3A2661A3.2A759525@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Original-CC: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... 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, 30 Nov 2000 08:18:11 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > So, figuring we didn't all have enough email on the sip list to read (I am > personally hopelessly behind), let me stir things around some more with > another proposal for something to ditch from the spec. [...] > So, my proposal is that we simplify. We only allow SDP in INVITE and then > provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds like a Dr. > Seuss rhyme, doesn't it?) Did you just get done watching "The Grinch" :-) [...] > I don't think its hard to deal with the re-INVITE while INVITE-is-active > case. The simplest solution is to reject the first INVITE and continue > processing with the second one, using the new SDP and all. > > Anyway, before getting into those details, what does the group think about > dropping the SDP-in-ACK and SDP-in-PRACK stuff? Personally, I do not have any problems dropping SDP-in-ACK and SDP-in-PRACK (modulo Arjun's note that dropping SDP-in-ACK may break SIP-H.323 implementations). However, getting a re-INVITE while processing an INVITE (for the same call) may get messy. My first impulse it to say that, from a developer's view- point, there is enough complexity while processing a normal INVITE: detecting and handling spiralled loops, request merging, forking, correlating response to multiple requests, etc. Is the added complexity of handling re-INVITEs worth it? Furthermore, will this break older implementations which at best may send a 4xx response with a Retry-After header, or at worst will not know what to do with the re-INVITE. I don't think RFC 2543 dealt with re-INVITEs. Just my $0.02. Best regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 10:03:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10765 for ; Thu, 30 Nov 2000 10:03:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EED71443D6; Thu, 30 Nov 2000 09:03:10 -0500 (EST) 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 DBA9344357 for ; Thu, 30 Nov 2000 09:02:49 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08128; Thu, 30 Nov 2000 10:02:39 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23538; Thu, 30 Nov 2000 10:02:38 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 10:02:39 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EABF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , "'Howard Hart'" , "Henning G. Schulzrinne" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 10:02:36 -0500 There are a couple of mitigating factors. One is that the big firewall vendors are starting to commit to supporting SIP. No names, sorry, NDA issues! Another is that commercial SIP firewall "side cars" are appearing. I had an enlightening conversation with my internal security folks about the relative merits of "in the firewall" and "in parallel with the regular firewall" approaches. They seemed content with the argument that a parallel approach would be best if traffic volume of RTP was high, but "in the existing firewall" was best otherwise. I remember arguing for what we called an "interim AH" security scheme in Megaco, because at the time, the embedded OSs did not support IPSEC, and it was pretty hard to add it unless you had source code (since the AH header goes between IP and anything else). We used a header in the Megaco payload. By the time the protocol came out, the OSs had been upgraded, so that most now have IPSEC, if not from the vendor, then a 3rd party. I wonder if we would have the same result here. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, November 30, 2000 12:23 AM > To: 'Howard Hart'; Henning G. Schulzrinne > Cc: Jonathan Rosenberg; 'sip@lists.bell-labs.com' > Subject: RE: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt > > > I think this all has to be taken within the context that the > entfw draft is > NOT meant to be a long term solution. It is a short term > hack, nothing more. > As such, I am not really worried about potential HTTPS > caching proxies (if > even possible) that might arise one or two years from now. > > The draft aims really to solve a chicken-and-egg problem. No > enterprise IT > admin is going to let SIP (let alone UDP based RTP) in or out of the > firewall until there is overwhelming demand and strong > reasons for them to > do so. These incentives come when enough internal users are > using services > and deriving business value from them. Unfortunately, that > won't ever happen > since the firewalls block SIP/RTP. So you see the problem. > Through what is, > in the best case, an ugly hack, we can get some usage going within > enterprises, and then the demand can grow, and then IT > departments will > change policies so that users can stop doing horrible things > like port 443 > tunneling, and rather use SIP the original way it was > designed to be used. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Howard Hart [mailto:hch@ipdialog.com] > > Sent: Tuesday, November 28, 2000 3:09 PM > > To: Henning G. Schulzrinne > > Cc: Jonathan Rosenberg; 'sip@lists.bell-labs.com' > > Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt > > > > > > Hi Henning, > > > > See responses below: > > > > "Henning G. Schulzrinne" wrote: > > > > > Howard Hart wrote: > > > > > > > > Jonathan and Henning, > > > > > > > > I think this is a great shot at tunneling SIP and RTP > > through Firewalls, > > > > though you may want to add the following caveats to section 6: > > > > > > > > 1) Wrt corporate tunneling, high-bandwidth voice > > traffic has a distinct > > > > network signature vs. (relatively) low-bandwidth Web > > traffic. If you blast > > > > voice traffic, encrypted or unencrypted over Web ports, > > it's going to stick out > > > > like a sore thumb even using the crudest network > > monitoring tools. ISS and the > > > > other network intrusion detection packages may even flag > > it as a Netbus, > > > > BackOrifice, or Distributed Denial of Service attack > > signature. Most network > > > > administrators will shut the originating host/port down > > immediately and ask > > > > questions later. > > > > > > I'm not sure whether that's a problem, as voice bandwidth > > is generally > > > much lower than web retrievals. (As low as 8 kb/s vs. a > few hundred > > > kilo*bytes*/second on my desktop to many web servers. If I > > download a > > > piece of software, it will easily consume as much bandwidth > > as a phone > > > call: 3 minute call = 180 seconds = 180 kBytes, which is > > smaller than > > > many individual web pages.) > > > > If the average Web page retrieval required 100+ > > kbytes/second, I don't think the > > average user on their 28.8 baud, 3-5 kbytes/second (w/VJ > > compression) modem would do > > much web surfing :-), but I get your point. My contention is > > divergence from Web > > traffic signatures will be highly dependent on a number of > > cumulative factors, from > > your locally provisioned bandwidth, to your usage patterns, > > to the number of times > > you access the same server, to the sensitivity of your > > intrusion detection package, > > to how long you stay on the phone, etc. If you throw in > > sustained, encrypted RTP > > packet rate signatures at 25-50 pps over several minutes with > > the added burden that > > only a small percentage of Web traffic is encrypted/port 443, > > it will probably > > trigger the alarms, but your mileage will vary depending on > > the level of paranoia at > > your local site. > > > > > > > > > > > > > > > > 2) The Internet backbone itself has been heavily > > optimized (some might say > > > > almost too optimized) for port 80 traffic, and is moving > > in that direction (as > > > > > > This is bogus, except for the web caching that some ISPs (but, > > > fortunately, by no means all ISPs) do. Routers don't know > > about port 80. > > > > Agreed, my wording was poor. More accurately, ISPs are > > deploying web caching engines > > at their edges to eliminate/optimize redundant HTTP/port 80 > > traffic over their > > backbones, especially when they're being used for transit vs. > > direct access to Web > > servers within their networks. > > > > > > > > > > > > much as is feasible) for port 443/HTTPS. Increasingly, > > ISPs are using Web > > > > caching engines to limit this traffic across their > > backbones. Case in point--I > > > > used Checkpoint's encrypted VPN product in a previous > > company to connect an > > > > overseas location to our site (encrypted payloads, port > > numbers stay the same). > > > > Our remote site wanted to access our internal Web server. > > Unfortunately, one of > > > > the intermediate ISPs was using a Web caching product, > > which resulted in the > > > > caching engine intercepting, then attempting to originate > > an (unauthorized) > > > > port 80 access to our internal Web server on the remote > > end's behalf, with the > > > > expected (non)result. The answer from the ISP was, of > > course, "well it works > > > > fine for all our normal customers--EOM". I think you'd > > see some very > > > > interesting side effects if you applied a tunneled RTP > > stream to this or other > > > > kinds of caching servers on port 80. > > > > Granted, 443/SSL-caching is a much more difficult > > problem, equating to a > > > > man-in-the- middle attack--maybe even unsolvable, but > > given the monetary > > > > inceptive is huge to come up with a solution here too, > > partial or otherwise.... > > > > > > Much of 443 traffic is inherently uncacheable, as it is for > > things like > > > forms responses from web orders. I doubt that even the > looniest ISP > > > would want to return your airline booking confirmation > page or bank > > > balance to me. Also, unless the cache has the certificate > > of the origin > > > server, intercept is just not possible. I doubt that > Citibank, say, > > > would hand out their private key to random ISPs. > > > > True, and as I stated above, maybe unsolvable, but for a > > sample of where pieces of > > this might come into play later on, check out > > http://www.f5.com/f5products/bigip/ecommerce, one of the more > > popular Web > > load-balancers. The advantage here is you offload encryption > > and key negotiation > > from individual servers in a large server farm and place the > > burden in hardware on > > the load-balancer. The question then becomes an ISP/SysAdmin > > policy issue as to > > whether you can locate your remote tunneling Proxy in front > > of or behind the > > load-balancer, and what's the impact when the load-balancer > > assumes all traffic on > > port 443 is HTTP only. > > > > NOTE: This is obviously NOT an issue for your scheme today. > > Just something to > > consider or maybe even take advantage of in the future. > > > > Howard Hart > > ipDialog, Inc. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 30 10: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 KAA17816 for ; Thu, 30 Nov 2000 10:19:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 570D244403; Thu, 30 Nov 2000 09:06:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.lg-elite.com (unknown [150.150.83.41]) by lists.bell-labs.com (Postfix) with ESMTP id 4EE404433A for ; Wed, 29 Nov 2000 19:21:18 -0500 (EST) Received: (from root@localhost) by mailgate.lg-elite.com (8.9.3/WhyDoYouWannaKnow) id KAA13391 for sip@lists.bell-labs.com.procmail; Thu, 30 Nov 2000 10:20:47 +0900 (KST) Received: from mail.lgcit.com (mail.lgcit.com [150.150.64.170]) by mailgate.lg-elite.com (8.9.3/WhyDoYouWannaKnow) with ESMTP id KAA13381 for ; Thu, 30 Nov 2000 10:20:46 +0900 (KST) Received: from 6734 (67-34.lgcit.com [150.150.67.34]) by mail.lgcit.com (8.8.8/8.8.8) with SMTP id KAA11296 for ; Thu, 30 Nov 2000 10:19:16 +0900 (KST) Message-ID: <00b501c05a6c$0b9e5eb0$22439696@lgcit.com> From: "Kim, DongSung" To: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailgate.lg-elite.com id KAA13381 Subject: [SIP] Processing BYE request at 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: Thu, 30 Nov 2000 10:22:46 +0900 Content-Transfer-Encoding: 8bit I have questions about BYE request.. My questions are two I am a Proxy. And I have received INVITE request from client and forked that to downstream.(now there is server and client call state in my proxy) And then I have receive BYE request which has the same call-leg with previous INVITE request but has lower CSeq than previous INVITE request. If I were UAS, I could reply 400(bad request). But I am proxy, So What Can I do in this case?(According to SPEC, Proxy cannot generate final response to BYE request) Of course, this situation is exceptional, But one of possible situation. I am a proxy. And I have received INVITE request from client and forked that to down stream.. And then I have received none-200 final responses from all branches.... so I have forwarded lowest numbered final response to upstream. But before I receive ACK for final response from upstream, I receive BYE request which has same call leg with previous INVITE request and has higher CSeq than previous INVITE request. According to SPEC, Proxy cannot generate final response to BYE request.. So there is no way but to simply forking BYE request to downstream. I think this generates unnecessary network traffic. I think If proxy could generated final response to BYE request without forking BYE request to downstream in this special case, there would be network bandwidth savings without malfunction. I want your opinion about this issue _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 10: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 KAA23352 for ; Thu, 30 Nov 2000 10:33:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 24814443F3; Thu, 30 Nov 2000 09:33:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 35570443B9 for ; Thu, 30 Nov 2000 09:32:20 -0500 (EST) Received: from CINQUECENTO ([63.110.3.222]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id KAA03753; Thu, 30 Nov 2000 10:34:25 -0500 (EST) From: "Robert Sparks" To: "Billy Biggs" , "Jonathan Rosenberg" Cc: "Alan Johnston" , "SIP List" Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 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: <20001130001436.A29311@div8.net> 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, 30 Nov 2000 09:29:59 -0600 Content-Transfer-Encoding: 7bit > Jonathan Rosenberg (jdrosen@dynamicsoft.com): > > >> The REFER transaction itself does not affect the old session. > >> However, to keep our phone UI simple, we disconnect the old call. > >> Users can't understand it otherwise. > > > > You are most definitely confusing a primitive operation (REFER), with > > a specific service, which is transfer. > > Understandably we need some primitive. I think we agree this > primitive is "initiate a session with the Refer-To address". Actually, it's do whatever makes sense in your UA for the URL. Keep in mind that non-SIP URLs are valid here. > > Due to the design constraints of our device, we cannot keep around > both calls. I suspect that a PSTN gateway would be in a similar > situation, since there is no way for the POTS phone to be able to > indicate this. When the new session is active, we disconnect the old. > > Yes, we are unable to use services which require the old call to stay > active. It's a constraint. But our implementation is completely > reasonable and we do follow the spec. > > > So far, the only service I've halted seems to be Music-On-Hold, which > requires that the far end have some crazy logic to send a BYE based on a > REFER anyways. I'm sure there will be other services that this device > won't be able to handle, but I'm not worried yet. What crazy logic? Building the request based on the method parameter and possibly header parameter in the URL? > > I suspect that other SIP devices which try to act like phones will > behave similarily, which is why I suggested to change the music call > flow to be more interoperability-friendly. > > > [...] Putting a Require header in to specify each service for which > > REFER might be used is a bad thing. Its the same as writing a formal > > protocol spec for each specific service. Our aim here was to build > > primitive operation which could be used to build many services, > > without every party knowing the service. Just the invoker needs to > > know how to map the services into protocol primitives. > > Yes, but there are two actors here. The sender of the REFER (who > knows the service it wants to provide) and the receiver of the REFER > (who doesn't). At least in this example, if we knew that the sender > really needed the call to stay up after the REFER completes, then we > could at least reject the REFER. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 10: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 KAA03755 for ; Thu, 30 Nov 2000 10:56:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8F4344418; Thu, 30 Nov 2000 09:56:09 -0500 (EST) 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 E98D9443E2 for ; Thu, 30 Nov 2000 09:55:13 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id JAA21459; Thu, 30 Nov 2000 09:53:33 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Thu, 30 Nov 2000 09:50:36 -0600 Message-ID: From: "Culpepper, Bert" To: Gethin Liddell , Sip Mail List Subject: RE: [SIP] 3PCC and the re-invite response MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 09:50:35 -0600 You bring up a good point IMO. Currently, a controller needs to check that A didn't change its SDP and if so, re-invite B. Could end up in an awful loop with both UAs. I agree that we need a way to guard against this situation. Your proposal seems reasonable to me. Regards, Bert > -----Original Message----- > From: Gethin Liddell [mailto:gethin@ubiquity.net] > Sent: Thursday, November 30, 2000 7:19 AM > To: Sip Mail List > Subject: [SIP] 3PCC and the re-invite response > > > > people, > > i'm slightly concerened (maybe un-justifably) about the re-invite > working of the 3PCC draft. > > my concern is that it is possible (is it not?) for the user agent > receiving the re-invite to change its SDP settings in its response as > follows: > > A Controller B > | INV held SDP | | > |<------------------| | > | | | > | 200 SDP A1 | | > |-----------------> | INV SDP A1 | > | ACK |----------------->| > |<----------------- | | > | | 200 SDP B1 | > | |<-----------------| > | | | > | | ACK | > | INV SDP B1 |----------------->| > |<------------------| | > | 200 OK SDP A2 | | > |------------------>| | > | ACK | | > |<------------------| | > | | > | BROKEN RTP | > | | > | | > | | > > NOTE: A has returned different SDP in its two different 200 OK > messages. > > Why might it do this? It might not but it is possible is it not. > > perhaps we should mandate that an agent can only change its SDP for a > session in an INVITE not in a response (after the initial > INVITE/RESPONSE exchange of course) > > what do we think? > > -- > 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 Thu Nov 30 11:04: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 LAA08062 for ; Thu, 30 Nov 2000 11:04:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EFD3A443B9; Thu, 30 Nov 2000 10:04:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id ECEB344357 for ; Thu, 30 Nov 2000 10:03:52 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 30 Nov 2000 10:03:43 -0600 (CST) From: Billy Biggs To: Robert Sparks Cc: Jonathan Rosenberg , Alan Johnston , SIP List Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 Message-ID: <20001130100343.A30059@div8.net> References: <20001130001436.A29311@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from rsparks@dynamicsoft.com on Thu, Nov 30, 2000 at 09:29:59AM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 30 Nov 2000 10:03:43 -0600 Robert Sparks (rsparks@dynamicsoft.com): >> So far, the only service I've halted seems to be Music-On-Hold, >> which requires that the far end have some crazy logic to send a BYE >> based on a REFER anyways. I'm sure there will be other services >> that this device won't be able to handle, but I'm not worried yet. > > What crazy logic? Building the request based on the method parameter > and possibly header parameter in the URL? I assume you want the BYE to be associated with the music call. Otherwise, that BYE would be sent with a new From tag and no To tag (a new call leg), and would not end the old call. Aside from that matching, there are also security implications of being able to tell a UA to send any SIP request, especially a BYE. I don't want a remote UA to tell me to hang up a call. So if some service requires this, then we have to do some logic to see if the user previously asked us to make a call such that we would allow them to send a BYE for it. Ugh. So, our security is simple: - Remote UA must have a call active to us (no out-of-call REFERs). - We will only allow REFERs which ask us to INVITE. - We will only allow being REFERed once (REFER is at the cost of the old session). More priviledges are available through something stronger (PHONECTL), which requires authentication. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 11:16: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 LAA13933 for ; Thu, 30 Nov 2000 11:16:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DBFEF44408; Thu, 30 Nov 2000 10:16:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 94F6E44407 for ; Thu, 30 Nov 2000 10:15:25 -0500 (EST) Received: from CINQUECENTO ([63.110.3.222]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id LAA04444; Thu, 30 Nov 2000 11:17:41 -0500 (EST) From: "Robert Sparks" To: "Billy Biggs" Cc: "Jonathan Rosenberg" , "Alan Johnston" , "SIP List" Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 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: <20001130100343.A30059@div8.net> 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, 30 Nov 2000 10:13:15 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Thursday, November 30, 2000 10:04 AM > To: Robert Sparks > Cc: Jonathan Rosenberg; Alan Johnston; SIP List > Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 > > > Robert Sparks (rsparks@dynamicsoft.com): > > >> So far, the only service I've halted seems to be Music-On-Hold, > >> which requires that the far end have some crazy logic to send a BYE > >> based on a REFER anyways. I'm sure there will be other services > >> that this device won't be able to handle, but I'm not worried yet. > > > > What crazy logic? Building the request based on the method parameter > > and possibly header parameter in the URL? > > I assume you want the BYE to be associated with the music call. > Otherwise, that BYE would be sent with a new From tag and no To tag (a > new call leg), and would not end the old call. Hence To: and From: headers in the URL. > > Aside from that matching, there are also security implications of > being able to tell a UA to send any SIP request, especially a BYE. I > don't want a remote UA to tell me to hang up a call. So if some service > requires this, then we have to do some logic to see if the user > previously asked us to make a call such that we would allow them to send > a BYE for it. Ugh. So your UA has a policy to always 503 sip: BYE URLs. > > So, our security is simple: > > - Remote UA must have a call active to us (no out-of-call REFERs). > - We will only allow REFERs which ask us to INVITE. > - We will only allow being REFERed once (REFER is at the cost of the > old session). > > More priviledges are available through something stronger (PHONECTL), > which requires authentication. You could require that your REFERs be SIP authenticated. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 11:26:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19395 for ; Thu, 30 Nov 2000 11:26:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAEFA44415; Thu, 30 Nov 2000 10:26:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CA2DC44407 for ; Thu, 30 Nov 2000 10:25:30 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA04645; Thu, 30 Nov 2000 11:27:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 11:23:24 -0500 Message-ID: From: Jonathan Rosenberg To: "'Gethin Liddell'" , Sip Mail List Subject: RE: [SIP] 3PCC and the re-invite response MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 11:23:20 -0500 This is a recognized problem. Note the following section in the document: In addition, note that in Figure 1, the controller sends a re-INVITE to A with the SDP from B. The response to this re-INVITE is a 200 OK that contains "SDP A". If the SDP returned in the re-INVITE response were not the same, the controller would need to initiate a re-INVITE to B with that new SDP. This means that a UA which returns a Rosenberg/Peterson/Schulzrinne/Camarillo [Page 12] Internet Draft 3pcc November 22, 2000 different SDP (for example, by changing the ports) in the response to every re-INVITE will trigger an infinite re-INVITE loop from the controller to each controller entity. As such, it is STRONGLY RECOMMENDED that if a re-INVITE does not require a UAS to modify the formulation of the SDP description for a specific stream in the response, the SDP description of that stream in the response MUST be the same. In other words, if a UA was in a session with a single stream, using codec A, and it received a re-INVITE modifying the port to send to, the re-INVITE response MUST be the same as it was to the initial request. However, if the re-INVITE forces the UAS to change codecs, it is acceptable in that case to use a different port in the SDP in the response. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Gethin Liddell [mailto:gethin@ubiquity.net] > Sent: Thursday, November 30, 2000 7:19 AM > To: Sip Mail List > Subject: [SIP] 3PCC and the re-invite response > > > > people, > > i'm slightly concerened (maybe un-justifably) about the re-invite > working of the 3PCC draft. > > my concern is that it is possible (is it not?) for the user agent > receiving the re-invite to change its SDP settings in its response as > follows: > > A Controller B > | INV held SDP | | > |<------------------| | > | | | > | 200 SDP A1 | | > |-----------------> | INV SDP A1 | > | ACK |----------------->| > |<----------------- | | > | | 200 SDP B1 | > | |<-----------------| > | | | > | | ACK | > | INV SDP B1 |----------------->| > |<------------------| | > | 200 OK SDP A2 | | > |------------------>| | > | ACK | | > |<------------------| | > | | > | BROKEN RTP | > | | > | | > | | > > NOTE: A has returned different SDP in its two different 200 > OK messages. > > Why might it do this? It might not but it is possible is it not. > > perhaps we should mandate that an agent can only change its SDP for a > session in an INVITE not in a response (after the initial > INVITE/RESPONSE exchange of course) > > what do we think? > > -- > 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 Thu Nov 30 11:48: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 LAA00268 for ; Thu, 30 Nov 2000 11:48:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D3BB044416; Thu, 30 Nov 2000 10:48:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id DC76A44357 for ; Thu, 30 Nov 2000 10:47:20 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 30 Nov 2000 10:47:11 -0600 (CST) From: Billy Biggs To: Robert Sparks Cc: Jonathan Rosenberg , Alan Johnston , SIP List Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 Message-ID: <20001130104711.A30137@div8.net> References: <20001130100343.A30059@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from rsparks@dynamicsoft.com on Thu, Nov 30, 2000 at 10:13:15AM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 30 Nov 2000 10:47:11 -0600 Robert Sparks (rsparks@dynamicsoft.com): >>>> So far, the only service I've halted seems to be Music-On-Hold, >>>> which requires that the far end have some crazy logic to send a BYE >>>> based on a REFER anyways. I'm sure there will be other services >>>> that this device won't be able to handle, but I'm not worried yet. >>> >>> What crazy logic? Building the request based on the method parameter >>> and possibly header parameter in the URL? >> >> I assume you want the BYE to be associated with the music call. >> Otherwise, that BYE would be sent with a new From tag and no To tag >> (a new call leg), and would not end the old call. > > Hence To: and From: headers in the URL. How can the referrer know what tag the far-end UA used? As well, using the supplied to/from is another security no-no. REFER should not be a control protocol. It does not supply enough information to properly orchestrate these operations. If you need this sort of functionality, let's keep it seperate, like PHONECTL. >> Aside from that matching, there are also security implications of >> being able to tell a UA to send any SIP request, especially a BYE. I >> don't want a remote UA to tell me to hang up a call. So if some >> service requires this, then we have to do some logic to see if the >> user previously asked us to make a call such that we would allow them >> to send a BYE for it. Ugh. > > So your UA has a policy to always 503 sip: BYE URLs. Right now we treat everything as an INVITE, but the plan would be to send a 403. >> So, our security is simple: >> >> - Remote UA must have a call active to us (no out-of-call REFERs). >> - We will only allow REFERs which ask us to INVITE. >> - We will only allow being REFERed once (REFER is at the cost of >> the old session). >> >> More priviledges are available through something stronger >> (PHONECTL), which requires authentication. > > You could require that your REFERs be SIP authenticated. Which would be the same as PHONECTL. The remote UA needs to know the phone's password to to do remote phone control operations. It doesn't seem reasonable for me to tell my phone's password to everyone who wants to play me music-on-hold. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 12:51:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27551 for ; Thu, 30 Nov 2000 12:51:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B58044437A; Thu, 30 Nov 2000 11:51:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id A469744357 for ; Thu, 30 Nov 2000 11:50:39 -0500 (EST) Received: from fokus.gmd.de (dhcp116 [195.37.78.244]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA26320; Thu, 30 Nov 2000 18:50:07 +0100 (MET) Message-ID: <3A269260.E61F8628@fokus.gmd.de> From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Cc: "'Jonathan Rosenberg'" , "'Howard Hart'" , "Henning G. Schulzrinne" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt References: <4FBEA8857476D311A03300204840E1CF01A6EABF@whq-msgusr-02.pit.comms.marconi.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, 30 Nov 2000 18:46:08 +0100 Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > > There are a couple of mitigating factors. > > One is that the big firewall vendors are starting to > commit to supporting SIP. No names, sorry, NDA issues! For example, Cisco claims to have SIP support in their latest PIX firewalls 5.2: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v52/pixrn521.htm#xtocid2350933 FYI: The "in parallel with the regular firewall" topic will be discussed at the MidCom BOF Jiri -- Jiri Kuthan http://www.fokus.gmd.de/usr/kuthan tel:+49-30-34637271 Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 13:05: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 NAA02959 for ; Thu, 30 Nov 2000 13:05:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 014C6443AA; Thu, 30 Nov 2000 12:05:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from westhost16.westhost.net (westhost16.westhost.com [216.71.84.74]) by lists.bell-labs.com (Postfix) with ESMTP id 5BE3E44357 for ; Thu, 30 Nov 2000 12:04:49 -0500 (EST) Received: from Hunter (w040.z208176180.sjc-ca.dsl.cnc.net [208.176.180.40]) by westhost16.westhost.net (8.8.5/8.8.5) with SMTP id MAA10617; Thu, 30 Nov 2000 12:10:19 -0600 From: "Tom Tang" To: "Jiri Kuthan" , "Rosen, Brian" Cc: "'Jonathan Rosenberg'" , "'Howard Hart'" , "Henning G. Schulzrinne" , Subject: RE: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt 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: <3A269260.E61F8628@fokus.gmd.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 10:08:04 -0800 Content-Transfer-Encoding: 7bit Jiri : Can you elaborate on what operations they support for SIP ? I looked through that link and on the Cisco website, but nada. Thanks. - Tom -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jiri Kuthan Sent: Thursday, November 30, 2000 9:46 AM To: Rosen, Brian Cc: 'Jonathan Rosenberg'; 'Howard Hart'; Henning G. Schulzrinne; 'sip@lists.bell-labs.com' Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt "Rosen, Brian" wrote: > > There are a couple of mitigating factors. > > One is that the big firewall vendors are starting to > commit to supporting SIP. No names, sorry, NDA issues! For example, Cisco claims to have SIP support in their latest PIX firewalls 5.2: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v52/pixrn521.h tm#xtocid2350933 FYI: The "in parallel with the regular firewall" topic will be discussed at the MidCom BOF Jiri -- Jiri Kuthan http://www.fokus.gmd.de/usr/kuthan tel:+49-30-34637271 Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 13:39: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 NAA16975 for ; Thu, 30 Nov 2000 13:39:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8172443A8; Thu, 30 Nov 2000 12:39:10 -0500 (EST) 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 9776844357 for ; Thu, 30 Nov 2000 12:38:41 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id NAA58776; Thu, 30 Nov 2000 13:38:31 -0500 (EST) Message-ID: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Jonathan Rosenberg" , "'Gethin Liddell'" , "Sip Mail List" References: Subject: Re: [SIP] 3PCC and the re-invite response 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, 30 Nov 2000 13:40:32 -0500 Content-Transfer-Encoding: 7bit BroadSoft uses the re-INVITE without SDP and ACK with SDP to avoid the possibility of both sides getting into the mentioned SDP change loop. This is why BroadSoft would like to keep the use of ACK with SDP at least with regard to re-INVITEs. This is also why it would be nice for rfc2543 to mention that an INVITE without SDP can be used as a request to pull the receiver off of hold. This has been discussed at the backoff and on the news group, but is currently not explicitly mentioned in rfc2543. ----- Original Message ----- From: Jonathan Rosenberg To: 'Gethin Liddell' ; Sip Mail List Sent: Thursday, November 30, 2000 11:23 AM Subject: RE: [SIP] 3PCC and the re-invite response > This is a recognized problem. Note the following section in the document: > > In addition, note that in Figure 1, the controller sends a re-INVITE > to A with the SDP from B. The response to this re-INVITE is a 200 OK > that contains "SDP A". If the SDP returned in the re-INVITE response > were not the same, the controller would need to initiate a re-INVITE > to B with that new SDP. This means that a UA which returns a > > > > Rosenberg/Peterson/Schulzrinne/Camarillo [Page 12] > > Internet Draft 3pcc November 22, 2000 > > > different SDP (for example, by changing the ports) in the response to > every re-INVITE will trigger an infinite re-INVITE loop from the > controller to each controller entity. As such, it is STRONGLY > RECOMMENDED that if a re-INVITE does not require a UAS to modify the > formulation of the SDP description for a specific stream in the > response, the SDP description of that stream in the response MUST be > the same. In other words, if a UA was in a session with a single > stream, using codec A, and it received a re-INVITE modifying the port > to send to, the re-INVITE response MUST be the same as it was to the > initial request. However, if the re-INVITE forces the UAS to change > codecs, it is acceptable in that case to use a different port in the > SDP in the response. > > > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Gethin Liddell [mailto:gethin@ubiquity.net] > > Sent: Thursday, November 30, 2000 7:19 AM > > To: Sip Mail List > > Subject: [SIP] 3PCC and the re-invite response > > > > > > > > people, > > > > i'm slightly concerened (maybe un-justifably) about the re-invite > > working of the 3PCC draft. > > > > my concern is that it is possible (is it not?) for the user agent > > receiving the re-invite to change its SDP settings in its response as > > follows: > > > > A Controller B > > | INV held SDP | | > > |<------------------| | > > | | | > > | 200 SDP A1 | | > > |-----------------> | INV SDP A1 | > > | ACK |----------------->| > > |<----------------- | | > > | | 200 SDP B1 | > > | |<-----------------| > > | | | > > | | ACK | > > | INV SDP B1 |----------------->| > > |<------------------| | > > | 200 OK SDP A2 | | > > |------------------>| | > > | ACK | | > > |<------------------| | > > | | > > | BROKEN RTP | > > | | > > | | > > | | > > > > NOTE: A has returned different SDP in its two different 200 > > OK messages. > > > > Why might it do this? It might not but it is possible is it not. > > > > perhaps we should mandate that an agent can only change its SDP for a > > session in an INVITE not in a response (after the initial > > INVITE/RESPONSE exchange of course) > > > > what do we think? > > > > -- > > 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 Thu Nov 30 14:06: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 OAA01026 for ; Thu, 30 Nov 2000 14:06:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7D03443CA; Thu, 30 Nov 2000 13:06:09 -0500 (EST) 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 F2B74443CA for ; Thu, 30 Nov 2000 13:05:31 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id OAA61886; Thu, 30 Nov 2000 14:05:19 -0500 (EST) Message-ID: <06ac01c05b00$c4670f70$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Jonathan Rosenberg" , References: Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... 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, 30 Nov 2000 14:07:21 -0500 Content-Transfer-Encoding: 7bit BroadSoft uses the re-INVITE without SDP and ACK with SDP to avoid the possibility of both sides getting into a SDP-change-loop discussed in thread "[SIP] 3PCC and the re-invite response". This is why BroadSoft would like to keep the use of ACK with SDP at least with regard to re-INVITEs. ----- Original Message ----- From: Jonathan Rosenberg To: Sent: Thursday, November 30, 2000 3:06 AM Subject: [SIP] as if there wasn't enough traffic on this darn list... > So, figuring we didn't all have enough email on the sip list to read (I am > personally hopelessly behind), let me stir things around some more with > another proposal for something to ditch from the spec. > > Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You > can send nothing in the INVITE, followed by SDP in the 200, and then SDP in > ACK (and fortunately I don't know anyone who actively does this). Or, you > can send SDP in INVITE, SDP in 200, and nothing in ACK. I also think there > are several confused implementations that likely send it in all three. > > Add to this the unfortunate PRACK mess, which also has been used to send SDP > in order to support the manyfolks resource work when used with 3pcc, but > which is yet unimplemented. > > It all adds up to a messy confusion. Its not clear what it means to send SDP > in all these places, and how it works. > > So, my proposal is that we simplify. We only allow SDP in INVITE and then > provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds like a Dr. > Seuss rhyme, doesn't it?) > > The latest 3pcc draft no longer recommends using the SDP-in-ACK, since it > has problems. Given that there don't seem to be useful applications of it > any longer, and given that, to my knowledge, it is not sent by anyone (at > least not in any commercially shipping boxes, I hope), I'd like to yank it. > > There is a consequence, and that is dealing with the manyfolks requirement > for sending an updated SDP to deal with manyfolks+3pcc. My proposal for that > is to use a re-invite, rahter than PRACK, to carry the updated SDP. This > does mean that we need to allow, in SIP, a re-INVITE to arrive while an > initial INVITE is in progress. Allowing this would also address some of the > concerns raised in previous threads about handling requirements for changes > in early media. > > I don't think its hard to deal with the re-INVITE while INVITE-is-active > case. The simplest solution is to reject the first INVITE and continue > processing with the second one, using the new SDP and all. > > Anyway, before getting into those details, what does the group think about > dropping the SDP-in-ACK and SDP-in-PRACK stuff? > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 14:49: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 OAA17650 for ; Thu, 30 Nov 2000 14:49:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2845A443C2; Thu, 30 Nov 2000 13:49:10 -0500 (EST) 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 467C744357 for ; Thu, 30 Nov 2000 13:48:42 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id BAA22885 for ; Fri, 1 Dec 2000 01:53:53 -0600 Message-ID: <01d201c05b06$3a2be320$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" 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 Subject: [SIP] Single Line Extension work Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 30 Nov 2000 13:42:20 -0600 Content-Transfer-Encoding: 7bit A while back we had a vigorous discussion going on how to implement the PBX/Centrex "single line extension" service or get behavior similar to US residentil "party lines". I don't believe I've seen any discussion on this topic for a long time. Anybody still working on it, or can we declare the effort dead for now? -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 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 SMTP id OAA19450 for ; Thu, 30 Nov 2000 14:53:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB58F44400; Thu, 30 Nov 2000 13:53:09 -0500 (EST) 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 2524B44357 for ; Thu, 30 Nov 2000 13:52:47 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11519; Thu, 30 Nov 2000 14:52:36 -0500 (EST) Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29017; Thu, 30 Nov 2000 14:52:39 -0500 (EST) Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 14:52:38 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EAC6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" Cc: "IETF SIP (E-mail)" Subject: RE: [SIP] Single Line Extension work 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, 30 Nov 2000 14:52:31 -0500 While I was one of the folks who are supposed to be working on it, I haven't been able to, so for now, I'd consider it dead. What I would say is until and unless someone brings at least a half baked draft explaining the issues, and proposing a reasonable mechanism, we declare it to be not an active WG item. Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, November 30, 2000 2:42 PM > To: IETF SIP (E-mail) > Subject: [SIP] Single Line Extension work > > > > A while back we had a vigorous discussion going on how to > implement the > PBX/Centrex "single line extension" service or get behavior > similar to US > residentil "party lines". > > I don't believe I've seen any discussion on this topic for a > long time. > Anybody still working on it, or can we declare the effort > dead for now? > > -- > Dean > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > 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 Nov 30 16:11: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 QAA18287 for ; Thu, 30 Nov 2000 16:11:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7A6FF44431; Thu, 30 Nov 2000 15:11:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 1CCC444437 for ; Thu, 30 Nov 2000 15:10:04 -0500 (EST) Received: from ORANLT (oran-home-ss20.cisco.com [171.69.210.4]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA02650; Thu, 30 Nov 2000 13:09:54 -0800 (PST) From: "David Oran" To: "'Jonathan Rosenberg'" , Subject: RE: [SIP] as if there wasn't enough traffic on this darn list... Organization: Cisco Systems Message-ID: <000301c05b11$e355da40$04d245ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2202 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: Thu, 30 Nov 2000 16:09:53 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA18287 Hmmm, I would simplify by going the OTHER direction and allowing SDP in any leg of an INVITE transaction. The meaning would be coupled with the state the transaction is in. This allows for 3-way negotiation of SDP, and allows very simple rules: the SDP you operate on, and reply to is the one you received in the last Request (INVITE or PRACK). The simple call scenarios don't get any more complicated: you use the most recent SDP sent, otherwise the most recent one you received. That gives much more flexibility and eliminates the special case rules as well. Is the liquid sloshing out of the pot yet? Dave. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Thursday, November 30, 2000 3:06 AM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] as if there wasn't enough traffic on this darn list... > > > So, figuring we didn't all have enough email on the sip list > to read (I am personally hopelessly behind), let me stir > things around some more with another proposal for something > to ditch from the spec. > > Right now, you can carry SDP in the INV/200/ACK exchange in > two ways. You can send nothing in the INVITE, followed by SDP > in the 200, and then SDP in ACK (and fortunately I don't know > anyone who actively does this). Or, you can send SDP in > INVITE, SDP in 200, and nothing in ACK. I also think there > are several confused implementations that likely send it in > all three. > > Add to this the unfortunate PRACK mess, which also has been > used to send SDP in order to support the manyfolks resource > work when used with 3pcc, but which is yet unimplemented. > > It all adds up to a messy confusion. Its not clear what it > means to send SDP in all these places, and how it works. > > So, my proposal is that we simplify. We only allow SDP in > INVITE and then provisionals/200 OK. No SDP in ACK. No SDP in > PRACK. (sounds like a Dr. Seuss rhyme, doesn't it?) > > The latest 3pcc draft no longer recommends using the > SDP-in-ACK, since it has problems. Given that there don't > seem to be useful applications of it any longer, and given > that, to my knowledge, it is not sent by anyone (at least not > in any commercially shipping boxes, I hope), I'd like to yank it. > > There is a consequence, and that is dealing with the > manyfolks requirement for sending an updated SDP to deal with > manyfolks+3pcc. My proposal for that is to use a re-invite, > rahter than PRACK, to carry the updated SDP. This does mean > that we need to allow, in SIP, a re-INVITE to arrive while an > initial INVITE is in progress. Allowing this would also > address some of the concerns raised in previous threads about > handling requirements for changes in early media. > > I don't think its hard to deal with the re-INVITE while > INVITE-is-active case. The simplest solution is to reject the > first INVITE and continue processing with the second one, > using the new SDP and all. > > Anyway, before getting into those details, what does the > group think about dropping the SDP-in-ACK and SDP-in-PRACK stuff? > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-> labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 17:43:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00699 for ; Thu, 30 Nov 2000 17:43:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BD4B3443E3; Thu, 30 Nov 2000 16:43:09 -0500 (EST) 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 3A1B244357 for ; Thu, 30 Nov 2000 16:42:54 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id EAA23469 for ; Fri, 1 Dec 2000 04:48:15 -0600 Message-ID: <02ea01c05b1e$95c89170$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" 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 Subject: [SIP] Discussion of Presentations at Upcoming Meeting Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 30 Nov 2000 16:20:03 -0600 Content-Transfer-Encoding: 7bit Folks, the last two meetings have been less satisfying than they might have been. I tried to wedge too many presentations into too little time and make everybody happy, and I did not leave enough time for discussion of important issues. This leads us to where we are -- behind on our deliverables, uncertain of what they are or should be, and faced with over a hundred active drafts and over twenty-five slot requests for the upcoming meetings, totaling a requested four hours not including any discussion time. I've heard several requests that that we allocate only one day to the "presentations" of drafts. This includes any new drafts that have had no previous discussion on the lists or are not work items of the group. We wold focus the other day on resolving open issues, the VAST majority of which have been brought up on the list against the bis draft such as record-routing in the reverse direction. We have two sessions -- Monday 1300-1500, and Tuesday 0900-1130. This gives us four and a half hours. I think we need to make some hard editorial decions according to the standard priorities: Priority 1: Originally chartered work. Priority 2: Work we have agreed to add to our charter. Priority 3: Everything else. I propose that we schedule Monday afternoon for discussion and Tuesday morning for presentations of drafts. I will prioritize the time Tuesday based on the above priorities, then by date of request arrival. -- Dean Willis _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 17:44: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 RAA01798 for ; Thu, 30 Nov 2000 17:44:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0AFDA44421; Thu, 30 Nov 2000 16:43:31 -0500 (EST) 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 BBF88443E3 for ; Thu, 30 Nov 2000 16:42:54 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id EAA23472 for ; Fri, 1 Dec 2000 04:48:15 -0600 Message-ID: <02eb01c05b1e$962111b0$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" 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 Subject: [SIP] Guidelines for Talks and Presentations at IETF 49 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk 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, 30 Nov 2000 16:27:58 -0600 Content-Transfer-Encoding: 7bit We're going to have an incredibly packed schedule at IETF 49. It will help if we can all minimize our presentations. Here are some suggestions on getting the most out of short presentations. For "new" material (00 drafts): -- Describe the basic problem -- Describe the proposed solution briefly -- Discuss known issues or stumbling points -- Propose further steps For "updated" material (0[~0]) drafts: -- Describe the changes from the previous draft -- Summarize issues or discussions -- Propose further steps 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 Thu Nov 30 20:53: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 UAA22363 for ; Thu, 30 Nov 2000 20:53:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B4A844412; Thu, 30 Nov 2000 19:53:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 0349344357 for ; Thu, 30 Nov 2000 19:52:37 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 17:52:15 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'David Oran'" , "'Jonathan Rosenberg'" , sip@lists.bell-labs.com Subject: RE: [SIP] as if there wasn't enough traffic on this darn list... 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, 30 Nov 2000 17:52:08 -0800 > > Hmmm, I would simplify by going the OTHER direction and > allowing SDP in any leg of an INVITE transaction. The meaning > would be coupled with the state the transaction is in. This > allows for 3-way negotiation of SDP, and allows very simple > rules: the SDP you operate on, and reply to is the one you > received in the last Request (INVITE or PRACK). > > The simple call scenarios don't get any more complicated: you > use the most recent SDP sent, otherwise the most recent one > you received. > > That gives much more flexibility and eliminates the special > case rules as well. It also removes the problem whereby one side doesn't support unannounced/arbitrary/intermixed vocoder changes or assymetric vocoder selections. eg INVITE has SDP with m=audio 12150 RTP/AVP 0 2 4 8 200 OK selects m=audio 12150 RTP/AVP 0 2 but caller's UA doesn't support multiple codecs or wants to use ony one vocoder, so send ACK re-selecting m=audio 12150 RTP/AVP 0 There _are_ implementations that are commercially shippped which support for SDP-in-ACK and people have tested this functionality at previous interop events (even tested with the Dynamicsoft UA). As H.323-SIP gateways start appearing on the market I think you will find more and more SIP user-agents wanting to support this function as they will want to interoperate with the all the Microsoft Netmeetings and existing H.323 equipment. I think there will be a lot of hidden problems and complexity with the suggested re-INVITE before INVITE completes. Implementation complexity (I feel) will be significantly higher and there great number of different message permutations that will need to be tested. I can't see it being very backwardly compatiable either. I do believe we need to fixed the re-INVITE glare mechanism which is (IMO) currently unworkable, this however is a separate problem. Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Nov 30 23:50: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 XAA01096 for ; Thu, 30 Nov 2000 23:50:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9CD71443D5; Thu, 30 Nov 2000 22:50:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 7DBDA44357 for ; Thu, 30 Nov 2000 22:49:02 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 20:48:40 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , SIP@lists.bell-labs.com Cc: Jonathan Rosenberg Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements 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, 30 Nov 2000 20:48:38 -0800 > > I don't think that proxies should start second-guessing UAS. > I would say that the simplest thing is just to say that when the > UA is building the Route header list, it should append the > Contact, if present; failing that, the From. > > Really old UAs might lose, but they were always going to do > that, anyway[0]. > What about in the other direction? The UAC will need to add a Record-Route for the _original_ Request-URI - which may in fact be entirely unhelpful. If the proxy were to add the extra Record-Route I think that is much safer as it knows what its own behaviour will be when it receives the request.. I guess, I was also trying to stick with the existing RFC2543 and bis UA behaviour (minus route mangling). Ie, the UA doesn't add an extra Route-Header for the original From or Request-URI - its only added if there is a Contact (which I think is a good thing !!). I think we can do better than saying RFC2543 doesn't work. - If a proxy inserts Record-Route header into a request without neither a Contact nor Record-Route header, then the Proxy MAY add a second Record-Route header to the end of the R-R list using the From URL address with the source address as an maddr parameter. - If a proxy receives a response to a request in which it added a Record-Route header AND the response does not contain a COntact header AND no new headers have been added by other proxies (ie proxy is final Record-Route'd proxy), then the proxy MAY add another preceeding Record-Route header to the start of the response's R-R list using the request's request-URI with the request's forward address as an maddr parameter. This should cover the majority of RFC2543 scenarios without too much fuss for the proxy or UA - I think it is better than trying to embed using r-r parameters as this just gets messya nd brittle. As I said before, I think it is better that the proxy does this as it understand that it will use the added Record-Route. If the UA tries this, it has little chance of success. A UA has never (if I remember correctly) added extra R-R headers if there is no Contact (and shouldn't matter even if it did). What do you think ? Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip