From sip-admin@lists.bell-labs.com Sat Jul 1 00:13:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03992 for ; Sat, 1 Jul 2000 00:13:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8DAA444365; Sat, 1 Jul 2000 00:11:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 10AF344336 for ; Sat, 1 Jul 2000 00:11:51 -0400 (EDT) Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02688; Sat, 1 Jul 2000 00:12:42 -0400 (EDT) Message-ID: <395D6FE1.D0D7EFC8@dynamicsoft.com> Date: Sat, 01 Jul 2000 00:13:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: Adam.Roach@Ericsson.com, rohan@cisco.com, oran@cisco.com, rfairlie@nuera.com, schulzrinne@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006291657.LAA10490@b04a45.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sean Olson wrote: > > > Adam, > > > > The "sprog" behavior reminds me of push advertising content. I am > > incredibly alarmed at the idea of displaying "sprog", or playing "sprog", > > or continually prompting me if I want to see "sprog". It's bad enough when > > I surf with cookie protection turned on. IMO, This non-semantically > > defined rendering is more appropriate for Instant Messaging. > > > > Now if you really want your UA to always display whatever content your peer > > barfs down to you, then I suggest we use headers, but create a convention > > that all the header names end with -Info. Then, when you get the headers: > > > > Sprog-Info: http://www.spam.com/annoying-animated.gif > > Sprog-Info: http://www.spam.com/annoying.wav > > > > Your UA can match against unknown *-Info headers and a) happily render > > them, b) prompt for them, or c) ignore them. > > It can quite easily do the same when matching unknown "purpose=" parameters > on a Display-Info: header. This is just a syntactical difference, not a > semantic one. I agree. The only semantic difference between a header vs. a purpose parameter is, as I and Adam pointed out, handling of unknown purposes. With a header, they are discarded. With a parameter, the policy of the UA could discard them or render them at its discretion. Since syntactic arguments are fundamentally futile, I think it is useful to make a decision based on the semantic differences. I prefer the more generally useful approach of using the parameter. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 1 02:58:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17289 for ; Sat, 1 Jul 2000 02:58:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E39244433E; Sat, 1 Jul 2000 02:58:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35]) by lists.bell-labs.com (Postfix) with ESMTP id C663144336 for ; Sat, 1 Jul 2000 02:58:03 -0400 (EDT) Received: from jana (bay-72.pppmad.vsnl.net.in [203.197.134.228] (may be forged)) by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id MAA16825 for ; Sat, 1 Jul 2000 12:24:25 +0530 (IST) Message-ID: <005c01bfe329$d97d6020$38c9a8c0@labs> From: "Pathangi N Janardhanan" To: References: <200006291657.LAA10490@b04a45.exu.ericsson.se> <395D6FE1.D0D7EFC8@dynamicsoft.com> Date: Sat, 1 Jul 2000 12:29:04 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] few questions Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, I have a few questions on implementation, and would appreciate some clarifications. a) The proxy/re-direct server needs to talk to a location server to resolve the addresse information. Is there any standard work for this interaction protocol, or in the absence of this, how would some one be able to write a SIP server to query the location server? b) Are there any requirements for scripts that the server must support, say CLP, XML etc? i.e. is there a minimum set that any server must understand? Is there any way for a client to know of this capability? Thanks Jana _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From mailman-owner@lists.bell-labs.com Sat Jul 1 05:14:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18031 for ; Sat, 1 Jul 2000 05:14:10 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EFD5A44730 for ; Sat, 1 Jul 2000 05:08:05 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: sip-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: Message-Id: <20000701090805.EFD5A44730@lists.bell-labs.com> Date: Sat, 1 Jul 2000 05:08:05 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, sip-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for sip-archive@lists.ietf.org: List Password // URL ---- -------- sip@lists.bell-labs.com TDGd http://lists.bell-labs.com/mailman/options/sip/sip-archive@lists.ietf.org From sip-admin@lists.bell-labs.com Sat Jul 1 09:29:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19834 for ; Sat, 1 Jul 2000 09:29:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C51C244349; Sat, 1 Jul 2000 09:29:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2CA6144336 for ; Sat, 1 Jul 2000 09:29:18 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA18041; Sat, 1 Jul 2000 09:29:16 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA15493; Sat, 1 Jul 2000 09:29:03 -0400 (EDT) Message-ID: <395DF21E.BC68B052@cs.columbia.edu> Date: Sat, 01 Jul 2000 09:29:02 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Sean Olson , Adam.Roach@Ericsson.com, rohan@cisco.com, oran@cisco.com, rfairlie@nuera.com, sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006291657.LAA10490@b04a45.exu.ericsson.se> <395D6FE1.D0D7EFC8@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Sean Olson wrote: > > > > > Adam, > > > > > > The "sprog" behavior reminds me of push advertising content. I am > > > incredibly alarmed at the idea of displaying "sprog", or playing "sprog", > > > or continually prompting me if I want to see "sprog". It's bad enough when > > > I surf with cookie protection turned on. IMO, This non-semantically > > > defined rendering is more appropriate for Instant Messaging. > > > > > > Now if you really want your UA to always display whatever content your peer > > > barfs down to you, then I suggest we use headers, but create a convention > > > that all the header names end with -Info. Then, when you get the headers: > > > > > > Sprog-Info: http://www.spam.com/annoying-animated.gif > > > Sprog-Info: http://www.spam.com/annoying.wav > > > > > > Your UA can match against unknown *-Info headers and a) happily render > > > them, b) prompt for them, or c) ignore them. > > > > It can quite easily do the same when matching unknown "purpose=" parameters > > on a Display-Info: header. This is just a syntactical difference, not a > > semantic one. > > I agree. > > The only semantic difference between a header vs. a purpose parameter > is, as I and Adam pointed out, handling of unknown purposes. With a > header, they are discarded. With a parameter, the policy of the UA could > discard them or render them at its discretion. Since syntactic arguments > are fundamentally futile, I think it is useful to make a decision based > on the semantic differences. I prefer the more generally useful approach > of using the parameter. > > I agree, but would tend to view semantic equivalence as somewhat more limited. For example, I don't think that error indication, ringing indication and additional information about caller/callee can just all be rendered if I don't recognize the purpose tag. As an example, if a client doesn't know about distinctive ringing, just rendering the header-indicated sound and local ringing at the same time is probably less than ideal. In the end, I don't think header vs. parameters doesn't matter all that much, so maybe it is more useful to gather applications for this: - ringing - caller/callee web page - caller/callee iconic/avatar representation (e.g., a small JPEG or GIF) - possibly error indication Anything else? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 1 10:03:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20224 for ; Sat, 1 Jul 2000 10:03:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B27D4434C; Sat, 1 Jul 2000 10:03:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 7E25544336 for ; Sat, 1 Jul 2000 10:03:36 -0400 (EDT) Received: (from shbhatna@localhost) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id KAA05278 for sip@lists.bell-labs.com; Sat, 1 Jul 2000 10:03:24 -0400 (EDT) From: Shail Bhatnagar Message-Id: <200007011403.KAA05278@bounty.cisco.com> To: sip@lists.bell-labs.com Date: Sat, 1 Jul 2000 10:03:24 -0400 (EDT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] "Legal" redirect loops Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The loop detection algorithm has been changed for proxies so that Request-URI is also included in it. This allows spiralling of requests. What is the policy for a client that is redirected. For example : INVITE sip:u@p ----------------> 302 Moved Temporarily <---------------- Contact: sip:x@p Should the client retry the INVITE with the changed request-URI. Note that this INVITE will be directed to same address and port. As per the bis version : "To avoid forwarding loops, a user agent client or proxy MUST check whether the address returned by a redirect server equals an address tried earlier. (Addresses match if their host and port number match.)" Comments ?? Thanks, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 1 10:32:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20386 for ; Sat, 1 Jul 2000 10:32:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 30C4C44351; Sat, 1 Jul 2000 10:31:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by lists.bell-labs.com (Postfix) with ESMTP id 0116F44336 for ; Sat, 1 Jul 2000 10:31:54 -0400 (EDT) Received: from 10.0.1.6 ([166.60.6.251]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTP id <01JR900A737O9KM2JR@shoe.reston.mci.net> for sip@lists.bell-labs.com; Sat, 1 Jul 2000 10:31:53 EST Date: Sat, 01 Jul 2000 07:31:50 -0700 From: Paul Krumviede Subject: Re: [SIP] PGP In-reply-to: <395D2A44.22F830A1@cs.columbia.edu> To: Henning Schulzrinne , Phil Hoffer , sip@lists.bell-labs.com Message-id: <364036196.962436710@[10.0.1.6]> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7BIT --On Friday, 30 June, 2000 19:16 -0400 Henning Schulzrinne wrote: > I can't tell for sure from the PGP documentation, but rsa does seem to > be the default. (The documentation for version 6.5, the latest, almost > makes it sound like that this depends on the version of the software.) I > added the missing parameter. New keys, by default, are actually a DSS signature key with a DH sub-key for encryption. The default signing/encryption operation is dependent on the key(s) used: if you have a DH/DSS key set, then DSA is the signature algorithm; the encryption algorithm depend on the recipient's key. If you have a windows version of PGP, run the key generation wizard and see what it does (if you have a version that will do both DH/DSS and RSA, it will suggest generating a DH/DSS key pair). -paul _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 1 13:24:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21144 for ; Sat, 1 Jul 2000 13:24:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D967B44351; Sat, 1 Jul 2000 13:24:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DEC6644336 for ; Sat, 1 Jul 2000 13:24:16 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA22971; Sat, 1 Jul 2000 13:24:15 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA19543; Sat, 1 Jul 2000 13:24:15 -0400 (EDT) Message-ID: <395E293F.A7D4A16E@cs.columbia.edu> Date: Sat, 01 Jul 2000 13:24:15 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Gethin Liddell , "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: <00062211545801.21137@gethin> <395316B3.DA6F3901@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Gethin Liddell wrote: > > > > However, as far as the Tel URI rfc (2806) is concerend, the character @ > > (for example) will not have to be escaped. This, of course, will not be > > valid in the sipurl as it is used to separate the `userinfo' and > > `hostinfo' elements and will need to be escaped. > > > > For example, if the phone-context is actually stored as: > > > > "Context1@Context2" > > > > then the tel url will have to look like: > > > > tel:+12345;phone-context=%22Context1@Context2%22 > > > > however, it would NOT be valid to just enter this as a sip url as > > follows: > > > > sip:+12345;phone-context=%22Context1@Context2%22@company.com;user=phone > > > > for the obvious problem of the @. this would need to be translated to: > > > > sip:+12345;phone-context=%22Context1%40Context2%22@company.com;user=phone > > Hmm. I wonder if the actual translation would be: > > sip:+12345;phone-context=%2522Context1%40Context2%2522@company.com;user=phone > > The difference is that here, I have treated the subscriber portion of > the tel URL as an opaque entity. When placing this into the user portion > of the SIP URL, I need to escape code reserved characters AND the % > itself. Effectively, I re-encoded the string, so that the two % signs > already there are treated as normal %, and thus escape encoded as %25. > > Which way to do it depends on whether you assume that the SIP entity has > knowledge of the structure of the tel URL subscriber syntax, in which > case it would know that this would have already had its % url-encoded, > and thus there is no need to redo that encoding, or whether it is > treated as a random username that happens to have some bad characters in > it. > > I tend to think the right answer is probably what Gethin has suggested. > In either case we should clarify this in the spec. > I don't think you want recursive escaping if you can help it, as it becomes difficult to make sure the right number of translations happen. Thus, the % should not be escaped, in my opinion. This is already implied in the BNF syntax for the 'user' part. However, the semicolon appears to be in the "needs to be escaped" category, which is annoying, since it is a syntactically important character. Escaping should only be used for characters that are opaque to the parsing of the URL, such as parameter values. Thus, in the slightly modified example from above, sip:+12345;phone-context=%3bContext1%40Context2%22@company.com;user=phone would really have to be written as sip:+12345%3bphone-context=%3bContext1%40Context2%22@company.com;user=phone which is rather confusing since the two %3b's mean very different things - the first is needed to understand the tel URL, the second is just a random character in a "context" parameter value (";Context1@Context2"). There seem to be only two solutions: - allow ; parameters in the user part. This probably works, although it means that a parser won't know whether this is a user parameter or generic parameter in a @-less URL until the end. It's probably too late to require a '@' in all URLs, even if the user part is empty. - double-escaping rules; seems to me a recipe for perpetual confusion and unlikely to be implemented correctly. Basically, URLs should be split along delimiters and then un-escaped for each part. That's 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 Sat Jul 1 13:57:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21289 for ; Sat, 1 Jul 2000 13:57:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E3984434D; Sat, 1 Jul 2000 13:57:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 0917B44336 for ; Sat, 1 Jul 2000 13:57:13 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA23653; Sat, 1 Jul 2000 13:57:11 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA20051; Sat, 1 Jul 2000 13:57:11 -0400 (EDT) Message-ID: <395E30F7.6BE60AF@cs.columbia.edu> Date: Sat, 01 Jul 2000 13:57:11 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ajay Chitturi Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Questions on Figure 11 of RFC2543bis References: <078292D50C98D2118D090008C7E9C6A6018A811C@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Ajay Chitturi wrote: > > In this diagram does "give up" mean the caller gave up and hung > up the call or that the state machine gave up ? This diagram is also a remnant of mixing transaction and call state. Since BYE and INVITE are separate transactions, you'd have to, strictly speaking, send a CANCEL when giving up, wait for the 487 response, in addition to a separate BYE transaction. However, this is not necessary, since the UAS will generate a 487 when it receives a BYE, cleaning out the INVITE transaction. The state diagram will reflect this in the next edition. > > Since there is another arrow from the "Calling" state showing > "7 INVITE sent", I assume the arrow to the right of "Calling" state > happens when the user hangs up. In this case shouldn't the state > machine > wait for the response to INVITE and send an ACK ? > > The arrow to the right of "Call Proceeding" state could happen if > either > the caller hangs up or the state machine hangs up. Is the timeout for > when > the state machine will give up in this state specified in the draft or > left > to the implementation. If the user hangs up, shouldn't the state > machine > wait for the response to INVITE and send an ACK ? > > Also section 4.2.4 states : > A BYE request from either called or calling party terminates any > pending INVITE, but the INVITE request transaction MUST be > completed > with a final response. > > Does this mean that the ACK also needs to be sent after getting > the response ? Yes; see above. > > Thanks > Ajay. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 1 14:16:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21432 for ; Sat, 1 Jul 2000 14:16:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2EA3D44363; Sat, 1 Jul 2000 14:15:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id CE87744352 for ; Sat, 1 Jul 2000 14:15:56 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA24173; Sat, 1 Jul 2000 14:15:55 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA20406; Sat, 1 Jul 2000 14:15:53 -0400 (EDT) Message-ID: <395E3559.52D820ED@cs.columbia.edu> Date: Sat, 01 Jul 2000 14:15:53 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Shail Bhatnagar , Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@cisco.com> <3953BC06.59B9275E@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Shail Bhatnagar wrote: > > > > I don't have a problem with this simplification - but the spec says > > an incoming request with Max-Forwards of 0 MUST NOT be forwarded. > > It does not say that the request cannot be locally processed and a > > response returned. Since REGISTER (for the registrar) and CANCEL > > will be absorbed by the proxy, I thought it is okay to process these > > requests. > > The relevant statement in the spec should be appropriately changed - > > > > request MUST NOT be forward and MUST NOT be processed. > > That is the proposal; as I said, I think it is very confusing otherwise. > > -Jonathan R. > Just for reference: Here's the HTTP/1.1 behavior: Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field MUST check and update its value prior to forwarding the request. If the received value is zero (0), the recipient MUST NOT forward the request; instead, it MUST respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message MUST contain an updated Max-Forwards field with a value decremented by one (1). The Max-Forwards header field MAY be ignored for all other methods defined by this specification and for any extension methods for which it is not explicitly referred to as part of that method definition. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 1 17:16:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22337 for ; Sat, 1 Jul 2000 17:16:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 917EF44353; Sat, 1 Jul 2000 17:16:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9A59544336 for ; Sat, 1 Jul 2000 17:16:01 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA03065; Sat, 1 Jul 2000 17:17:18 -0400 (EDT) Message-ID: <395E5F40.E893438C@dynamicsoft.com> Date: Sat, 01 Jul 2000 17:14:40 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.bell-labs.com Subject: Re: [SIP] "Legal" redirect loops References: <200007011403.KAA05278@bounty.cisco.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > The loop detection algorithm has been changed for proxies so that Request-URI > is also included in it. This allows spiralling of requests. What is > the policy for a client that is redirected. For example : > > INVITE sip:u@p > ----------------> > > 302 Moved Temporarily > <---------------- > Contact: sip:x@p > > Should the client retry the INVITE with the changed request-URI. Note that > this INVITE will be directed to same address and port. Yes (if it wants to, of course). > As per the bis version : > > "To avoid forwarding loops, a user agent client or proxy MUST check whether > the address returned by a redirect server equals an address tried earlier. Sounds good so far. > (Addresses match if their host and port number match.)" Well, this quote is taken from the previous paragraph, which talks about Via headers: "Any redirection (3xx) response MUST NOT suggest any of the addresses in the Via path of the request in the Contact header field. (Addresses match if their host and port number match.)" I believe this is an artifact from RFC 2543, which never mentions spiral loops. --- 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 Sat Jul 1 17:30:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22383 for ; Sat, 1 Jul 2000 17:30:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2BE444359; Sat, 1 Jul 2000 17:30:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id ADBA944336 for ; Sat, 1 Jul 2000 17:30:32 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA03078; Sat, 1 Jul 2000 17:31:49 -0400 (EDT) Message-ID: <395E62A4.4EA8D296@dynamicsoft.com> Date: Sat, 01 Jul 2000 17:29:08 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Pathangi N Janardhanan Cc: sip@lists.bell-labs.com Subject: Re: [SIP] few questions References: <200006291657.LAA10490@b04a45.exu.ericsson.se> <395D6FE1.D0D7EFC8@dynamicsoft.com> <005c01bfe329$d97d6020$38c9a8c0@labs> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Pathangi N Janardhanan wrote: > > a) The proxy/re-direct server needs to talk to a location server to > resolve the addresse > information. Is there any standard work for this interaction > protocol, or in the absence > of this, how would some one be able to write a SIP server to query > the location server? This is left undefined on purpose, namely, to standard internet principle of not defining anything that is not necessary for interoperability. Take a look at sec. 1.4.5 of RFC2543bis for the description of a few possible user location mechanisms. > b) Are there any requirements for scripts that the server must > support, say CLP, XML > etc? i.e. is there a minimum set that any server must understand? No. It all depends on what services you want to provide to your customers. > Is there any way for a client to know of this capability? Why would it want to know? Script execution is transparent to user agents. --- 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 Sun Jul 2 11:56:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08571 for ; Sun, 2 Jul 2000 11:56:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C6BF344345; Sun, 2 Jul 2000 11:56:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 5CB8844336 for ; Sun, 2 Jul 2000 11:56:20 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Sun, 2 Jul 2000 08:57:14 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: Gethin Liddell , sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Sun, 2 Jul 2000 08:57:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Thankfully semicolons are not allowed in private prefixes. I believe the only place a ';' is allowed in is the quoted string in the future-extension parameter value. This should mean that the purpose of the two are discernable, correct ? [Henning, in your example you wrote %3bContext1%40Context2%22 and inferred that this referred to ";Context1@Context2". Did you really mean that the context is ";Context1@Context2\"" or is the escaped string incorrect?] Cheers, Robert. > > I don't think you want recursive escaping if you can help it, as it > becomes difficult to make sure the right number of > translations happen. > Thus, the % should not be escaped, in my opinion. This is already > implied in the BNF syntax for the 'user' part. However, the semicolon > appears to be in the "needs to be escaped" category, which is > annoying, > since it is a syntactically important character. Escaping > should only be > used for characters that are opaque to the parsing of the URL, such as > parameter values. Thus, in the slightly modified example from above, > > sip:+12345;phone-context=%3bContext1%40Context2%22@company.com > ;user=phone > > would really have to be written as > > sip:+12345%3bphone-context=%3bContext1%40Context2%22@company.c > om;user=phone > > which is rather confusing since the two %3b's mean very > different things > - the first is needed to understand the tel URL, the second is just a > random character in a "context" parameter value > (";Context1@Context2"). > > There seem to be only two solutions: > > - allow ; parameters in the user part. This probably works, > although it > means that a parser won't know whether this is a user parameter or > generic parameter in a @-less URL until the end. It's > probably too late > to require a '@' in all URLs, even if the user part is empty. > > - double-escaping rules; seems to me a recipe for perpetual confusion > and unlikely to be implemented correctly. Basically, URLs should be > split along delimiters and then un-escaped for each part. That's 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jul 2 12:01:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08645 for ; Sun, 2 Jul 2000 12:01:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2906A4435B; Sun, 2 Jul 2000 12:01:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 05A1A44359 for ; Sun, 2 Jul 2000 12:01:06 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA21191; Sun, 2 Jul 2000 12:01:04 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA13288; Sun, 2 Jul 2000 12:01:02 -0400 (EDT) Message-ID: <395F673E.F6D02D1B@cs.columbia.edu> Date: Sun, 02 Jul 2000 12:01:02 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: Jonathan Rosenberg , Gethin Liddell , sip@lists.bell-labs.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > Thankfully semicolons are not allowed in private prefixes. I believe the > only place a ';' is allowed in is the quoted string in the future-extension > parameter value. This should mean that the purpose of the two are > discernable, correct ? ; are used all over in the tel URL to delineate parameters, so I'm not sure I understand your point here. > > [Henning, in your example you wrote %3bContext1%40Context2%22 and inferred > that this referred to ";Context1@Context2". Did you really mean that the > context is ";Context1@Context2\"" or is the escaped string incorrect?] Yes, this is a valid, if somewhat unlikely, context name. -- 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 Jul 2 21:40:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12761 for ; Sun, 2 Jul 2000 21:40:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A612744350; Sun, 2 Jul 2000 21:40:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 9DA7244336 for ; Sun, 2 Jul 2000 21:40:46 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Sun, 2 Jul 2000 18:41:41 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" Cc: Jonathan Rosenberg , Gethin Liddell , sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Sun, 2 Jul 2000 18:41:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi Henning, > ; are used all over in the tel URL to delineate parameters, so I'm not > sure I understand your point here. > > > [Henning, in your example you wrote > %3bContext1%40Context2%22 and inferred > > that this referred to ";Context1@Context2". Did you really > mean that the > > context is ";Context1@Context2\"" or is the escaped string > incorrect?] > > Yes, this is a valid, if somewhat unlikely, context name. > The private-prefix is defined as (from RFC2806) 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] Thus the semicolon (%x3b) is not allowed (assuming we are not using recursive escaping). However semicolons are allowed in the quoted-string token (see below). The quoting I believe is sufficient to differentiate between a semicolon delineating parameters and a future-extension parameter value. future-extension = ";" 1*(token-char) ["=" ((1*(token-char) ["?" 1*(token-char)]) / quoted-string )] ; See section 2.5.11 and [RFC2543] token-char = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7A / %x7C / %x7E) ; Characters in URLs must follow escaping rules ; as explained in [RFC2396] ; See sections 1.2 and 2.5.11 quoted-string = %x22 *( "\" CHAR / (%x20-21 / %x23-7E / %x80-FF )) %x22 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 Mon Jul 3 07:09:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28925 for ; Mon, 3 Jul 2000 07:09:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D60E44352; Mon, 3 Jul 2000 07:08:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.gte.com (unknown [132.197.8.26]) by lists.bell-labs.com (Postfix) with ESMTP id CAE0244336 for ; Mon, 3 Jul 2000 07:08:41 -0400 (EDT) Received: from sigmail.gte.com (sigmail.gte.com [132.197.120.75]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id HAA25930; Mon, 3 Jul 2000 07:08:36 -0400 (EDT) Received: by sigmail.gte.com with Internet Mail Service (5.5.2232.9) id ; Mon, 3 Jul 2000 07:07:18 -0400 Message-ID: From: "Gardell, Steve" To: "'Matt Holdrege'" , Henry Sinnreich Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP->XML->SOAP Date: Mon, 3 Jul 2000 07:07:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have been on vacation, so appologies for the belated response. After struggling to explain "softswitches" to operations folks here, we settled on a very general definition that could be taken to include MG's, SIP Proxy Servers, H.323 routed GK's as well as the more switch-like constructs being defined by the Multi-Media Switching Forum. However, as near as we can tell, today "softswitch" is a marketing term most closely associated with the IETF MG. What definition is implicit in the "value" commentary here? Steven Gardell GTE Laboratories Voice: 781-466-2681, Fax: 781-466-3375 > -----Original Message----- > From: Matt Holdrege [mailto:matt@ipverse.com] > Sent: Wednesday, June 21, 2000 4:32 PM > To: Henry Sinnreich > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP->XML->SOAP > > > At 07:09 AM 6/18/00 -0500, Henry Sinnreich wrote: > > >> SIP->XML would converge the SIP methods and required > > >parameters to XML and > > >> allows the introduction of a DTD or schema to define > > >the syntax of a valid > > >> SIP message. > > > >Do not forget that endangering the deployment of SIP as is, > >would set IP telephony back for a generation and leave the field > >for "softswitches" and other such nonsense. Nobody on this > >mailing list would then live to see true/open Internet > >communications, but just the old circuit switch central control > >model with its terrible signaling. Just using IP as a cheap > >wire. > > Henry, > > This is the first time I recall seeing "softswitches" being > denigrated on > an IETF list. I would hope you realize that they are an > enabler to get the > circuit switched world to migrate to open communications? Saying that > Softswitches will preserve the circuit switched world with > it's "terrible > signalling" is a bit short-sighted. > > You should also realize that SIP is doing quite well in the > area of market > acceptance. The more people buy into SIP the more evolution will be > required. Change is inevitable even though we must try to > manage it well. > XML is one such change that seems (to me) to be inevitable. > So it would be > better to try and manage the interactions with SIP and XML > here in the IETF > rather than elsewhere. Besides, it's part of the openess that > we all should > encourage. > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 3 07:43:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29493 for ; Mon, 3 Jul 2000 07:43:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF5C444337; Mon, 3 Jul 2000 07:43:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 61F4B44336 for ; Mon, 3 Jul 2000 07:43:30 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA16506; Mon, 3 Jul 2000 12:41:07 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Fairlie-Cuninghame, Robert" , "'Henning Schulzrinne'" Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Mon, 3 Jul 2000 10:40:51 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: Jonathan Rosenberg , sip@lists.bell-labs.com References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00070312353001.26755@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi, i see this thread has taken off whilst I've been on holiday :) but here's my pennies worth anyway: #1 Private-prefix, semi-colons, recursion and Henning's example: Robert is correct that semi-colons are not allowed in the private-prefix part of the TEL URI. So Henning's example of sip:+12345%3bphone-context=%3bContext1%40Context2%22@company.com;user=phone is invalid because the phone-context=%3bContext1%40Context2%22 will be un-escaped to phone-context=;Context1@Context2" So although the escaped version is not syntactically invalid, the un-escaped is grammatically invalid. However, ignoring this, i think this is a very important point being made by Henning here. Take the case where we have the TEL URI with two future-extension parameters a=b@c and d=;e. Now for this to be a valid TEL URI, it MUST be written as: TEL:+1234;a=b@c;d=%3be We now have to convert this to sip and we have the problem. Do we allow semi-colon's in userinfo: (1) ------- sip:+1234;a=b%40c;d=%3be@host or do we escape the semi-colon's: (2) ------- sip:+1234%3ba=b%40c%3bd=%3be@host Well straight away, (2) is incorrect because this will be un-escaped to +1234;a=b@c;d=;e which is evidently different to what we started with So (2) should be double escaped to read: (3) ------- sip:+1234%3ba=b%40c%3bd=%253be@host So which is best? Well, I can't help but feel that adding `;' to user is a bit of a hack. Would we not need to add `?' as well because of exactly the same arguments for `;' I personally am split between the two. Are there any other arguments that we haven't thought about? Is the double escaping method not more generic? OK, it's more difficult to read but a computer doesn't worry abut that! However, that means we would have to escape the `%' in `d=%3be' again. Does the escaping of the `@' not complicated things and thus require that the `%3b' be escaped to `%253b' anyway? #2 Quoted Strings in URIs. I really do not like quoted strings in URIs. For the main reason that the quote character is defined invalid in the Generic URI RFC 2396 (Section 2.4 and 2.4.3). It is explicitly defined in the said rfc that the quote character is invalid because it is used as a delimiter else where (along with other characters). Any time a quoted string is required, the quotes would have to be escaped to be valid. This would also mean that a lot of internal data would have to be escaped. For example if we have a simple URI as follows: myURI:abcdef;token="quoted string" Then this could only be used as myURI:asbcef;token=%22quoted%20string%22 note the space MUST be escaped as well. Why do i mention this? Because it worries me when i see emails saying: On Mon, 03 Jul 2000, Fairlie-Cuninghame, Robert wrote: > Thus the semicolon (%x3b) is not allowed (assuming we are not using > recursive escaping). However semicolons are allowed in the quoted-string > token (see below). The quoting I believe is sufficient to differentiate > between a semicolon delineating parameters and a future-extension parameter > value. Even though the semi colon is allowed in the quoted string, it would still have to be escaped a long with all the other reserved or invalid characters. If this was not the case, it would be impossible to parse an Unknown URI as an opaque string because you would not know where it starts or stops or what the characters actually mean within the escaped string. I actually contacted the author of the TEL URI over this fact and informed him that we had agreed to remove the escaped-string from the future-extension of the Sip URL and asked him what his thoughts were. Here was the reply: > Oh well... It seems that I weeded out all non-allowed chars from > in my BNF but forgot about ... I think I trusted > RFC 2543 too much. Now whether this means that quoted string has now been removed from TEL URI I'm not sure. Either way it is a mute point point because if a quoted string is to be used then it would have to be escaped into an opaque string anyway. This could and probably would look very messy. I think I've covered everything ;) -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 3 11:29:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03277 for ; Mon, 3 Jul 2000 11:29:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CC1364433F; Mon, 3 Jul 2000 11:29:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.gte.com (unknown [132.197.8.26]) by lists.bell-labs.com (Postfix) with ESMTP id 3C15644336 for ; Mon, 3 Jul 2000 11:29:07 -0400 (EDT) Received: from sigmail.gte.com (sigmail.gte.com [132.197.120.75]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id LAA12823; Mon, 3 Jul 2000 11:28:57 -0400 (EDT) Received: by sigmail.gte.com with Internet Mail Service (5.5.2232.9) id ; Mon, 3 Jul 2000 11:27:39 -0400 Message-ID: From: "Gardell, Steve" To: "'Matt Holdrege'" , "'Henry Sinnreich'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP->XML->SOAP Date: Mon, 3 Jul 2000 11:27:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I apologize for the double posting. Read "MGC" rather than "MG". What I get for going on vacation... > -----Original Message----- > From: Gardell, Steve > Sent: Monday, July 03, 2000 7:07 AM > To: 'Matt Holdrege'; Henry Sinnreich > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP->XML->SOAP > > > I have been on vacation, so appologies for the > belated response. After struggling to explain > "softswitches" to operations folks here, we > settled on a very general definition that could > be taken to include MG's, SIP Proxy Servers, > H.323 routed GK's as well as the more switch-like > constructs being defined by the Multi-Media > Switching Forum. However, as near as we can tell, > today "softswitch" is a marketing term most > closely associated with the IETF MG. > > What definition is implicit in the "value" commentary > here? > > Steven Gardell > GTE Laboratories > Voice: 781-466-2681, Fax: 781-466-3375 > > > > -----Original Message----- > > From: Matt Holdrege [mailto:matt@ipverse.com] > > Sent: Wednesday, June 21, 2000 4:32 PM > > To: Henry Sinnreich > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] SIP->XML->SOAP > > > > > > At 07:09 AM 6/18/00 -0500, Henry Sinnreich wrote: > > > >> SIP->XML would converge the SIP methods and required > > > >parameters to XML and > > > >> allows the introduction of a DTD or schema to define > > > >the syntax of a valid > > > >> SIP message. > > > > > >Do not forget that endangering the deployment of SIP as is, > > >would set IP telephony back for a generation and leave the field > > >for "softswitches" and other such nonsense. Nobody on this > > >mailing list would then live to see true/open Internet > > >communications, but just the old circuit switch central control > > >model with its terrible signaling. Just using IP as a cheap > > >wire. > > > > Henry, > > > > This is the first time I recall seeing "softswitches" being > > denigrated on > > an IETF list. I would hope you realize that they are an > > enabler to get the > > circuit switched world to migrate to open communications? > Saying that > > Softswitches will preserve the circuit switched world with > > it's "terrible > > signalling" is a bit short-sighted. > > > > You should also realize that SIP is doing quite well in the > > area of market > > acceptance. The more people buy into SIP the more evolution will be > > required. Change is inevitable even though we must try to > > manage it well. > > XML is one such change that seems (to me) to be inevitable. > > So it would be > > better to try and manage the interactions with SIP and XML > > here in the IETF > > rather than elsewhere. Besides, it's part of the openess that > > we all should > > encourage. > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/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 Jul 3 11:50:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03725 for ; Mon, 3 Jul 2000 11:50:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6AEB04436A; Mon, 3 Jul 2000 11:48:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 9739C44336 for ; Mon, 3 Jul 2000 11:48:34 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA23371; Mon, 3 Jul 2000 11:48:22 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA11108; Mon, 3 Jul 2000 11:48:09 -0400 (EDT) Message-ID: <3960B5B9.6E609F5F@cs.columbia.edu> Date: Mon, 03 Jul 2000 11:48:09 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: sip@lists.bell-labs.com, antti.vaha-sipila@nokia.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: <00070312353001.26755@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gethin Liddell wrote: > > Hi, > > > However, ignoring this, i think this is a very important point being > made by Henning here. Take the case where we have the TEL URI with two > future-extension parameters a=b@c and d=;e. Now for this to be a > valid TEL URI, it MUST be written as: > > TEL:+1234;a=b@c;d=%3be > > We now have to convert this to sip and we have the problem. > > Do we allow semi-colon's in userinfo: > > (1) ------- sip:+1234;a=b%40c;d=%3be@host > > or do we escape the semi-colon's: > > (2) ------- sip:+1234%3ba=b%40c%3bd=%3be@host > > Well straight away, (2) is incorrect because this will be un-escaped to > > +1234;a=b@c;d=;e > > which is evidently different to what we started with So (2) should be > double escaped to read: > > (3) ------- sip:+1234%3ba=b%40c%3bd=%253be@host > > So which is best? Well, I can't help but feel that adding `;' to user > is a bit of a hack. Would we not need to add `?' as well because of > exactly the same arguments for `;' I personally am split between the > two. Are there any other arguments that we haven't thought about? Is > the double escaping method not more generic? OK, it's more difficult > to read but a computer doesn't worry abut that! However, that means we > would have to escape the `%' in `d=%3be' again. Does the escaping of > the `@' not complicated things and thus require that the `%3b' be > escaped to `%253b' anyway? > My main concern with double escaping is that it's difficult to get right across different software versions. The software has to keep track of what state of escaping various pieces of string are in, how they have been passed along by other pieces (such as external cgi scripts) and so on. I don't even want to think about what this means for comparisons. Single-level escaping is already a pain. There is another, smaller problem (I hope I didn't misread the hex listing this time...): The colon (:, 3a) is legal in private-prefix. However, this is also used in the user:password separator, as in sip:alice:secret@whatever.com and sip:1234;phone-context=:mycontext This can be solved by escaping the ":" (which is probably a good idea anyway since it's an RFC 2396 "reserved" character - I'm surprised this is legit at all). Therefore, I'd suggest that either all tel URL "meta" characters (? and semicolon, I believe) are valid in the user part or that these parts are "exported" to the end of the SIP URL. The latter idea is ugly, but at least syntactically workable. My preference is to allow ; and ? in user-info, but none of the three solutions is blessed by aesthetics, so I'm largely agnostic as long as somebody can produce a simple, unambiguous description of the mechanism. > #2 Quoted Strings in URIs. > I really do not like quoted strings in URIs. For the main reason that > the quote character is defined invalid in the Generic URI RFC 2396 > (Section 2.4 and 2.4.3). It is explicitly defined in the said rfc that > the quote character is invalid because it is used as a delimiter else > where (along with other characters). Any time a quoted string is > required, the quotes would have to be escaped to be valid. This would > also mean that a lot of internal data would have to be escaped. > > For example if we have a simple URI as follows: > > myURI:abcdef;token="quoted string" > > Then this could only be used as > > myURI:asbcef;token=%22quoted%20string%22 > > note the space MUST be escaped as well. > > Why do i mention this? Because it worries me when i see emails saying: > > On Mon, 03 Jul 2000, Fairlie-Cuninghame, Robert wrote: > > Thus the semicolon (%x3b) is not allowed (assuming we are not using > > recursive escaping). However semicolons are allowed in the quoted-string > > token (see below). The quoting I believe is sufficient to differentiate > > between a semicolon delineating parameters and a future-extension parameter > > value. > > Even though the semi colon is allowed in the quoted string, it would > still have to be escaped a long with all the other reserved or invalid > characters. If this was not the case, it would be impossible to parse > an Unknown URI as an opaque string because you would not know where it > starts or stops or what the characters actually mean within the escaped > string. > > I actually contacted the author of the TEL URI over this fact and > informed him that we had agreed to remove the escaped-string from the > future-extension of the Sip URL and asked him what his thoughts were. > > Here was the reply: > > > Oh well... It seems that I weeded out all non-allowed chars from > > in my BNF but forgot about ... I think I trusted > > RFC 2543 too much. > > Now whether this means that quoted string has now been removed from TEL > URI I'm not sure. Either way it is a mute point point because if a > quoted string is to be used then it would have to be escaped into an > opaque string anyway. This could and probably would look very messy. > > I think I've covered everything ;) Yes, the topic of quoted strings in SIP URLs was discussed on this list a while ago and there was agreement to remove this "feature" from SIP URLs. It shouldn't have been there to begin with. I would suggest that tel URLs take the same approach before the spec moves from Proposed to Draft Standard. (As long as we keep people from using the feature, this is not too onerous in terms of backward compatibility.) Mixing two quoting mechanisms (quotation marks and %xx) is a recipe for confusion. -- 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 Jul 3 12:09:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04074 for ; Mon, 3 Jul 2000 12:09:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E36F64433D; Mon, 3 Jul 2000 12:09:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id B1FC544336 for ; Mon, 3 Jul 2000 12:09:36 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA24525; Mon, 3 Jul 2000 17:07:31 +0100 (BST) Message-ID: <3960BA42.B6E2B68E@ubiquity.net> Date: Mon, 03 Jul 2000 17:07:30 +0100 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: "Gardell, Steve" Cc: "'Henry Sinnreich'" , "'sip@lists.bell-labs.com'" Subject: Softswitches (was Re: [SIP] SIP->XML->SOAP) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Check out: http://www.computertelephony.com/article/CTM20000608S0021 As Henry explains in more detail here where a 'Softswitch' is used to preserve the signaling and control architecture of SS7 and the Intelligent Network the vendor who implements the Softswitch owns control over services. This reinvents the failings of the IN/PSTN whereas SIP seeks to build new services and empower service creation by end users. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net "Gardell, Steve" wrote: > > I apologize for the double posting. Read > "MGC" rather than "MG". What I get for > going on vacation... > > > -----Original Message----- > > From: Gardell, Steve > > Sent: Monday, July 03, 2000 7:07 AM > > To: 'Matt Holdrege'; Henry Sinnreich > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] SIP->XML->SOAP > > > > > > I have been on vacation, so appologies for the > > belated response. After struggling to explain > > "softswitches" to operations folks here, we > > settled on a very general definition that could > > be taken to include MG's, SIP Proxy Servers, > > H.323 routed GK's as well as the more switch-like > > constructs being defined by the Multi-Media > > Switching Forum. However, as near as we can tell, > > today "softswitch" is a marketing term most > > closely associated with the IETF MG. > > > > What definition is implicit in the "value" commentary > > here? > > > > Steven Gardell > > GTE Laboratories > > Voice: 781-466-2681, Fax: 781-466-3375 > > > > > > > -----Original Message----- > > > From: Matt Holdrege [mailto:matt@ipverse.com] > > > Sent: Wednesday, June 21, 2000 4:32 PM > > > To: Henry Sinnreich > > > Cc: sip@lists.bell-labs.com > > > Subject: RE: [SIP] SIP->XML->SOAP > > > > > > > > > At 07:09 AM 6/18/00 -0500, Henry Sinnreich wrote: > > > > >> SIP->XML would converge the SIP methods and required > > > > >parameters to XML and > > > > >> allows the introduction of a DTD or schema to define > > > > >the syntax of a valid > > > > >> SIP message. > > > > > > > >Do not forget that endangering the deployment of SIP as is, > > > >would set IP telephony back for a generation and leave the field > > > >for "softswitches" and other such nonsense. Nobody on this > > > >mailing list would then live to see true/open Internet > > > >communications, but just the old circuit switch central control > > > >model with its terrible signaling. Just using IP as a cheap > > > >wire. > > > > > > Henry, > > > > > > This is the first time I recall seeing "softswitches" being > > > denigrated on > > > an IETF list. I would hope you realize that they are an > > > enabler to get the > > > circuit switched world to migrate to open communications? > > Saying that > > > Softswitches will preserve the circuit switched world with > > > it's "terrible > > > signalling" is a bit short-sighted. > > > > > > You should also realize that SIP is doing quite well in the > > > area of market > > > acceptance. The more people buy into SIP the more evolution will be > > > required. Change is inevitable even though we must try to > > > manage it well. > > > XML is one such change that seems (to me) to be inevitable. > > > So it would be > > > better to try and manage the interactions with SIP and XML > > > here in the IETF > > > rather than elsewhere. Besides, it's part of the openess that > > > we all should > > > encourage. > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- 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 Jul 3 12:32:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04518 for ; Mon, 3 Jul 2000 12:32:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A58044368; Mon, 3 Jul 2000 12:32:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.gte.com (unknown [132.197.8.26]) by lists.bell-labs.com (Postfix) with ESMTP id 8257344336 for ; Mon, 3 Jul 2000 12:32:00 -0400 (EDT) Received: from sigmail.gte.com (sigmail.gte.com [132.197.120.75]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id MAA18116; Mon, 3 Jul 2000 12:31:52 -0400 (EDT) Received: by sigmail.gte.com with Internet Mail Service (5.5.2232.9) id <3GRG5GAP>; Mon, 3 Jul 2000 12:30:34 -0400 Message-ID: From: "Gardell, Steve" To: "'Neil Deason'" Cc: "'Henry Sinnreich'" , "'sip@lists.bell-labs.com'" Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) Date: Mon, 3 Jul 2000 12:30:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Thanks for the pointer Neil. Given current market-driven definitions, Henry's description (definition) of softswitches is reasonable, but I would note that a number of vendors talk of using "softswitches" in contexts where there is no (direct) SS7 signaling. For example one leading telcom vendor used a "softswitch" as a foundation for a new IP-PBX. Also, "softswitches" are promoted as "interior" service platforms (e.g. not controlling any MG's) by several large telcom vendors. SIP is a wonderful tool for service creation in it's own right, but I don't think that Henry's article really does justice to "API approaches" to service creation and standardization such as JAIN/JTAPI. At the least a reasoned discounting might be in order. Lastly, in a heterogeneous world order (where it just ain't all IP), it seems to me that softswitches are a step in the right direction, especially if we allow that it is a "poor softswitch that is not also a SIP Proxy." As a representative of the company (Verizon) with the largest number of POTS lines in the US, I am not sure what choice I have... Steven Gardell GTE Laboratories Voice: 781-466-2681, Fax: 781-466-3375 > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Monday, July 03, 2000 12:08 PM > To: Gardell, Steve > Cc: 'Henry Sinnreich'; 'sip@lists.bell-labs.com' > Subject: Softswitches (was Re: [SIP] SIP->XML->SOAP) > > > Check out: > > http://www.computertelephony.com/article/CTM20000608S0021 > > As Henry explains in more detail here where a 'Softswitch' > is used to preserve the signaling and control architecture > of SS7 and the Intelligent Network the vendor who implements > the Softswitch owns control over services. This reinvents > the failings of the IN/PSTN whereas SIP seeks to build new > services and empower service creation by end users. > > Cheers, > Neil > -- > Ubiquity Software Corporation, UK > http://www.ubiquity.net > > "Gardell, Steve" wrote: > > > > I apologize for the double posting. Read > > "MGC" rather than "MG". What I get for > > going on vacation... > > > > > -----Original Message----- > > > From: Gardell, Steve > > > Sent: Monday, July 03, 2000 7:07 AM > > > To: 'Matt Holdrege'; Henry Sinnreich > > > Cc: sip@lists.bell-labs.com > > > Subject: RE: [SIP] SIP->XML->SOAP > > > > > > > > > I have been on vacation, so appologies for the > > > belated response. After struggling to explain > > > "softswitches" to operations folks here, we > > > settled on a very general definition that could > > > be taken to include MG's, SIP Proxy Servers, > > > H.323 routed GK's as well as the more switch-like > > > constructs being defined by the Multi-Media > > > Switching Forum. However, as near as we can tell, > > > today "softswitch" is a marketing term most > > > closely associated with the IETF MG. > > > > > > What definition is implicit in the "value" commentary > > > here? > > > > > > Steven Gardell > > > GTE Laboratories > > > Voice: 781-466-2681, Fax: 781-466-3375 > > > > > > > > > > -----Original Message----- > > > > From: Matt Holdrege [mailto:matt@ipverse.com] > > > > Sent: Wednesday, June 21, 2000 4:32 PM > > > > To: Henry Sinnreich > > > > Cc: sip@lists.bell-labs.com > > > > Subject: RE: [SIP] SIP->XML->SOAP > > > > > > > > > > > > At 07:09 AM 6/18/00 -0500, Henry Sinnreich wrote: > > > > > >> SIP->XML would converge the SIP methods and required > > > > > >parameters to XML and > > > > > >> allows the introduction of a DTD or schema to define > > > > > >the syntax of a valid > > > > > >> SIP message. > > > > > > > > > >Do not forget that endangering the deployment of SIP as is, > > > > >would set IP telephony back for a generation and leave > the field > > > > >for "softswitches" and other such nonsense. Nobody on this > > > > >mailing list would then live to see true/open Internet > > > > >communications, but just the old circuit switch central control > > > > >model with its terrible signaling. Just using IP as a cheap > > > > >wire. > > > > > > > > Henry, > > > > > > > > This is the first time I recall seeing "softswitches" being > > > > denigrated on > > > > an IETF list. I would hope you realize that they are an > > > > enabler to get the > > > > circuit switched world to migrate to open communications? > > > Saying that > > > > Softswitches will preserve the circuit switched world with > > > > it's "terrible > > > > signalling" is a bit short-sighted. > > > > > > > > You should also realize that SIP is doing quite well in the > > > > area of market > > > > acceptance. The more people buy into SIP the more > evolution will be > > > > required. Change is inevitable even though we must try to > > > > manage it well. > > > > XML is one such change that seems (to me) to be inevitable. > > > > So it would be > > > > better to try and manage the interactions with SIP and XML > > > > here in the IETF > > > > rather than elsewhere. Besides, it's part of the openess that > > > > we all should > > > > encourage. > > > > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Ubiquity Software Corporation, UK > http://www.ubiquity.net > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 3 13: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 ESMTP id NAA05140 for ; Mon, 3 Jul 2000 13:20:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F391044364; Mon, 3 Jul 2000 13:20:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ns.fmmo.ca (www.fmmo.ca [207.253.160.156]) by lists.bell-labs.com (Postfix) with ESMTP id 576A144336 for ; Mon, 3 Jul 2000 13:20:15 -0400 (EDT) Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id NAA09953; Mon, 3 Jul 2000 13:49:47 -0400 Date: Mon, 3 Jul 2000 13:49:46 -0400 (EDT) From: fm-listproc To: "Fox, Mike" Cc: Sean Olson , sip@lists.bell-labs.com Subject: RE: [SIP] SIP->XML->SOAP In-Reply-To: <613A6A6A3F09D3118F5C00508B2C24FE7F362C@sd_exchange.nuera.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > (SIP->XML)->SOAP would change the transport to HTTP ( I know HTTP may need > some fixing ie. TCP -> SCTP), and change SIP from a protocol to a set of > object interfaces exposed by the SOAP schema. The SIP "methods" would become > object interface methods. Events could be defined through event object > interface methods. Device control can be defined similarly. Actually, the SOAP specification does not require that HTTP be used for transport. I personally believe that an XML DTD for SIP servers is a good alternative to formalize an IDL for SIP servers in a manner that is more friendly than the SIP CGI approach. -=Francois=- > > > Mike > > > -----Original Message----- > > From: Sean Olson [mailto:eussean@exu.ericsson.se] > > Sent: Friday, June 16, 2000 11:37 AM > > To: mfox@nuera.com > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] SIP->XML->SOAP > > > > > > > I agree. I believe (SIP -> XML) -> SOAP(like)HTTP is > > unstoppable. OSP and > > > IMPP require XML awareness in SIP devices, so the door has > > already been > > > opened for XML convergence of the SIP domain. HTTP is the Internet > > > Application Protocol. The problems of HTTP using TCP can be > > fixed with SCTP > > > (I hope!). Of course this will take some time (12+ months). > > > > > > Shouldn't this be the direction of SIP? > > > Comments? > > > > > > > > > Mike Fox > > > > If you mean using XML as a common body format, I agree. If > > you mean SOAP, > > I think this is better solved with HTTP. SOAP is an > > interesting alternative > > for service execution in a SIP network. I don't think > > carrying it via SIP > > is necessary or really buys you anything in this case. But it > > certainly > > is a possibility. > > > > -- > > Sean Olson > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 3 15:48:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06874 for ; Mon, 3 Jul 2000 15:48:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B5C154436F; Mon, 3 Jul 2000 15:48:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id 15CBD44336 for ; Mon, 3 Jul 2000 15:48:18 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FX5009010CB4Q@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 3 Jul 2000 19:48:11 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FX50062V0CBMX@firewall.mcit.com>; Mon, 03 Jul 2000 19:48:11 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0FX50030105CRN@pmismtp04.wcomnet.com>; Mon, 03 Jul 2000 19:44:00 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FX50030105BRK@pmismtp04.wcomnet.com>; Mon, 03 Jul 2000 19:44:00 +0000 (GMT) Received: from C25776A ([166.44.138.111]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FX500HE004HF9@pmismtp04.wcomnet.com>; Mon, 03 Jul 2000 19:43:44 +0000 (GMT) Date: Mon, 03 Jul 2000 14:47:12 -0500 From: Henry Sinnreich Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) In-reply-to: To: "'Neil Deason'" , "Gardell, Steve" Cc: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit In the Internet context, which is the only one of interest for this IETF list, a softswitch seems to be a marketing term for an IP telephony gateway that acts as a SIP UA on the IP side. This has been mentioned below by Steve Gardell. There is nothing wrong with it. (There seem also to be trademark applications from several vendors that include the name "softswitch"). Also no problem with >"softswitches" are promoted as >"interior" service platforms (e.g. not controlling >any MG's) by several large telecom vendors. Problems seem to arise when circuit switch vendors promote the softswitch as an "exterior" service platform, across the net. Even without going into the technical issues, it seems we would then end up with a "Softswitchnet" instead of the Internet. This seemed far fetched to me until I actually heard a circuit switch vendor promoting the "Next Generation Public Network" that actually went so far as to discard the Internet completely! More problems arise when a GC is promoted to control IP phones. In this case, a competitor to the operator for that GC could not extend features to the GC controlled phones. This is a prime example of fogging up the Internet, actually of reinventing unequal access at the control level. Besides, how do you integrate the services of xGCP phones with other services on the Internet? The above may be mistaken opinions, but there are also questions such as, how does a softswitch environment handle: Presence? Instant Messaging? Unified Messaging? Caller and called preferences? Mobility? I suspect softswitch designers can find a way to solve all the above, but how will such an approach compare to SIP? Is it targeted to be an IETF standard? Would appreciate any insight from the list. Some time ago, SIP and H.323 comparisons were made in a number of places. Is it now time to make SIP-softswitch comparisons? Thanks, Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >Gardell, Steve >Sent: Monday, July 03, 2000 11:31 AM >To: 'Neil Deason' >Cc: 'Henry Sinnreich'; 'sip@lists.bell-labs.com' >Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) > > >Thanks for the pointer Neil. > >Given current market-driven definitions, Henry's >description (definition) of softswitches is >reasonable, but I would note that a number >of vendors talk of using "softswitches" in >contexts where there is no (direct) SS7 >signaling. For example one leading telcom >vendor used a "softswitch" as a foundation >for a new IP-PBX. Also, "softswitches" are promoted as >"interior" service platforms (e.g. not controlling >any MG's) by several large telcom vendors. > >SIP is a wonderful tool for service creation in >it's own right, but I don't think that Henry's article >really does justice to "API approaches" to service >creation and standardization such as JAIN/JTAPI. >At the least a reasoned discounting might be in >order. > >Lastly, in a heterogeneous world order (where it >just ain't all IP), it seems to me that softswitches >are a step in the right direction, especially if >we allow that it is a "poor softswitch that is >not also a SIP Proxy." As a representative of the >company (Verizon) with the largest number of POTS >lines in the US, I am not sure what choice I have... > >Steven Gardell >GTE Laboratories >Voice: 781-466-2681, Fax: 781-466-3375 > > >> -----Original Message----- >> From: Neil Deason [mailto:ndeason@ubiquity.net] >> Sent: Monday, July 03, 2000 12:08 PM >> To: Gardell, Steve >> Cc: 'Henry Sinnreich'; 'sip@lists.bell-labs.com' >> Subject: Softswitches (was Re: [SIP] SIP->XML->SOAP) >> >> >> Check out: >> >> http://www.computertelephony.com/article/CTM20000608S0021 >> >> As Henry explains in more detail here where a 'Softswitch' >> is used to preserve the signaling and control architecture >> of SS7 and the Intelligent Network the vendor who implements >> the Softswitch owns control over services. This reinvents >> the failings of the IN/PSTN whereas SIP seeks to build new >> services and empower service creation by end users. >> >> Cheers, >> Neil >> -- >> Ubiquity Software Corporation, UK >> http://www.ubiquity.net >> >> "Gardell, Steve" wrote: >> > >> > I apologize for the double posting. Read >> > "MGC" rather than "MG". What I get for >> > going on vacation... >> > >> > > -----Original Message----- >> > > From: Gardell, Steve >> > > Sent: Monday, July 03, 2000 7:07 AM >> > > To: 'Matt Holdrege'; Henry Sinnreich >> > > Cc: sip@lists.bell-labs.com >> > > Subject: RE: [SIP] SIP->XML->SOAP >> > > >> > > >> > > I have been on vacation, so appologies for the >> > > belated response. After struggling to explain >> > > "softswitches" to operations folks here, we >> > > settled on a very general definition that could >> > > be taken to include MG's, SIP Proxy Servers, >> > > H.323 routed GK's as well as the more switch-like >> > > constructs being defined by the Multi-Media >> > > Switching Forum. However, as near as we can tell, >> > > today "softswitch" is a marketing term most >> > > closely associated with the IETF MG. >> > > >> > > What definition is implicit in the "value" commentary >> > > here? >> > > >> > > Steven Gardell >> > > GTE Laboratories >> > > Voice: 781-466-2681, Fax: 781-466-3375 >> > > >> > > >> > > > -----Original Message----- >> > > > From: Matt Holdrege [mailto:matt@ipverse.com] >> > > > Sent: Wednesday, June 21, 2000 4:32 PM >> > > > To: Henry Sinnreich >> > > > Cc: sip@lists.bell-labs.com >> > > > Subject: RE: [SIP] SIP->XML->SOAP >> > > > >> > > > >> > > > At 07:09 AM 6/18/00 -0500, Henry Sinnreich wrote: >> > > > > >> SIP->XML would converge the SIP methods >and required >> > > > > >parameters to XML and >> > > > > >> allows the introduction of a DTD or >schema to define >> > > > > >the syntax of a valid >> > > > > >> SIP message. >> > > > > >> > > > >Do not forget that endangering the deployment >of SIP as is, >> > > > >would set IP telephony back for a generation >and leave >> the field >> > > > >for "softswitches" and other such nonsense. >Nobody on this >> > > > >mailing list would then live to see true/open Internet >> > > > >communications, but just the old circuit >switch central control >> > > > >model with its terrible signaling. Just using >IP as a cheap >> > > > >wire. >> > > > >> > > > Henry, >> > > > >> > > > This is the first time I recall seeing >"softswitches" being >> > > > denigrated on >> > > > an IETF list. I would hope you realize that they are an >> > > > enabler to get the >> > > > circuit switched world to migrate to open >communications? >> > > Saying that >> > > > Softswitches will preserve the circuit >switched world with >> > > > it's "terrible >> > > > signalling" is a bit short-sighted. >> > > > >> > > > You should also realize that SIP is doing >quite well in the >> > > > area of market >> > > > acceptance. The more people buy into SIP the more >> evolution will be >> > > > required. Change is inevitable even though we >must try to >> > > > manage it well. >> > > > XML is one such change that seems (to me) to >be inevitable. >> > > > So it would be >> > > > better to try and manage the interactions with >SIP and XML >> > > > here in the IETF >> > > > rather than elsewhere. Besides, it's part of >the openess that >> > > > we all should >> > > > encourage. >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > SIP mailing list >> > > > SIP@lists.bell-labs.com >> > > > http://lists.bell-labs.com/mailman/listinfo/sip >> > > > >> > > >> > >> > _______________________________________________ >> > SIP mailing list >> > SIP@lists.bell-labs.com >> > http://lists.bell-labs.com/mailman/listinfo/sip >> >> -- >> Ubiquity Software Corporation, UK >> http://www.ubiquity.net >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 3 17:03:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07672 for ; Mon, 3 Jul 2000 17:03:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 64DB044377; Mon, 3 Jul 2000 17:03:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from crash.netspeak.com (unknown [208.143.140.6]) by lists.bell-labs.com (Postfix) with ESMTP id 21DEF44336 for ; Mon, 3 Jul 2000 17:03:10 -0400 (EDT) Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Jul 2000 17:02:06 -0400 Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A6098506@crash.engineering.netspeak.com> From: "Neville O'reilly" To: "'Gardell, Steve'" , "'Neil Deason'" Cc: "'Henry Sinnreich'" , "'sip@lists.bell-labs.com'" Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) Date: Mon, 3 Jul 2000 17:02:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 1) I did not know "Verizon" was a company - yet (although the Genuity IPO seems to remove the last major obstacle.) 2) the term "softswitch" does not denote a switch - is it not most often used for a call control and processing agent (Call Agent , MGC are pretty syonomous terms? - a term that came about in the context of the adoption of a 3 layer "architecture" which separates services, call control and infrastructure/gateways from each other. It has nothing to do intrinsically with end user controlled vs. network controlled services. SOftswitch implementations could range from consumer software distributed on a CD to network centric call processors which manage large mediation switches and MGs with high port densities through MGCP signalling and talk to each other via SIP - for example. -----Original Message----- From: Gardell, Steve [mailto:sgardell@gte.com] Sent: Monday, July 03, 2000 12:31 PM To: 'Neil Deason' Cc: 'Henry Sinnreich'; 'sip@lists.bell-labs.com' Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) Thanks for the pointer Neil. Given current market-driven definitions, Henry's description (definition) of softswitches is reasonable, but I would note that a number of vendors talk of using "softswitches" in contexts where there is no (direct) SS7 signaling. For example one leading telcom vendor used a "softswitch" as a foundation for a new IP-PBX. Also, "softswitches" are promoted as "interior" service platforms (e.g. not controlling any MG's) by several large telcom vendors. SIP is a wonderful tool for service creation in it's own right, but I don't think that Henry's article really does justice to "API approaches" to service creation and standardization such as JAIN/JTAPI. At the least a reasoned discounting might be in order. Lastly, in a heterogeneous world order (where it just ain't all IP), it seems to me that softswitches are a step in the right direction, especially if we allow that it is a "poor softswitch that is not also a SIP Proxy." As a representative of the company (Verizon) with the largest number of POTS lines in the US, I am not sure what choice I have... Steven Gardell GTE Laboratories Voice: 781-466-2681, Fax: 781-466-3375 > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Monday, July 03, 2000 12:08 PM > To: Gardell, Steve > Cc: 'Henry Sinnreich'; 'sip@lists.bell-labs.com' > Subject: Softswitches (was Re: [SIP] SIP->XML->SOAP) > > > Check out: > > http://www.computertelephony.com/article/CTM20000608S0021 > > As Henry explains in more detail here where a 'Softswitch' > is used to preserve the signaling and control architecture > of SS7 and the Intelligent Network the vendor who implements > the Softswitch owns control over services. This reinvents > the failings of the IN/PSTN whereas SIP seeks to build new > services and empower service creation by end users. > > Cheers, > Neil > -- > Ubiquity Software Corporation, UK > http://www.ubiquity.net > > "Gardell, Steve" wrote: > > > > I apologize for the double posting. Read > > "MGC" rather than "MG". What I get for > > going on vacation... > > > > > -----Original Message----- > > > From: Gardell, Steve > > > Sent: Monday, July 03, 2000 7:07 AM > > > To: 'Matt Holdrege'; Henry Sinnreich > > > Cc: sip@lists.bell-labs.com > > > Subject: RE: [SIP] SIP->XML->SOAP > > > > > > > > > I have been on vacation, so appologies for the > > > belated response. After struggling to explain > > > "softswitches" to operations folks here, we > > > settled on a very general definition that could > > > be taken to include MG's, SIP Proxy Servers, > > > H.323 routed GK's as well as the more switch-like > > > constructs being defined by the Multi-Media > > > Switching Forum. However, as near as we can tell, > > > today "softswitch" is a marketing term most > > > closely associated with the IETF MG. > > > > > > What definition is implicit in the "value" commentary > > > here? > > > > > > Steven Gardell > > > GTE Laboratories > > > Voice: 781-466-2681, Fax: 781-466-3375 > > > > > > > > > > -----Original Message----- > > > > From: Matt Holdrege [mailto:matt@ipverse.com] > > > > Sent: Wednesday, June 21, 2000 4:32 PM > > > > To: Henry Sinnreich > > > > Cc: sip@lists.bell-labs.com > > > > Subject: RE: [SIP] SIP->XML->SOAP > > > > > > > > > > > > At 07:09 AM 6/18/00 -0500, Henry Sinnreich wrote: > > > > > >> SIP->XML would converge the SIP methods and required > > > > > >parameters to XML and > > > > > >> allows the introduction of a DTD or schema to define > > > > > >the syntax of a valid > > > > > >> SIP message. > > > > > > > > > >Do not forget that endangering the deployment of SIP as is, > > > > >would set IP telephony back for a generation and leave > the field > > > > >for "softswitches" and other such nonsense. Nobody on this > > > > >mailing list would then live to see true/open Internet > > > > >communications, but just the old circuit switch central control > > > > >model with its terrible signaling. Just using IP as a cheap > > > > >wire. > > > > > > > > Henry, > > > > > > > > This is the first time I recall seeing "softswitches" being > > > > denigrated on > > > > an IETF list. I would hope you realize that they are an > > > > enabler to get the > > > > circuit switched world to migrate to open communications? > > > Saying that > > > > Softswitches will preserve the circuit switched world with > > > > it's "terrible > > > > signalling" is a bit short-sighted. > > > > > > > > You should also realize that SIP is doing quite well in the > > > > area of market > > > > acceptance. The more people buy into SIP the more > evolution will be > > > > required. Change is inevitable even though we must try to > > > > manage it well. > > > > XML is one such change that seems (to me) to be inevitable. > > > > So it would be > > > > better to try and manage the interactions with SIP and XML > > > > here in the IETF > > > > rather than elsewhere. Besides, it's part of the openess that > > > > we all should > > > > encourage. > > > > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Ubiquity Software Corporation, UK > http://www.ubiquity.net > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 3 17: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 ESMTP id RAA07726 for ; Mon, 3 Jul 2000 17:12:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7B2044386; Mon, 3 Jul 2000 17:11:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from marlborough.cnchost.com (marlborough.concentric.net [207.155.248.14]) by lists.bell-labs.com (Postfix) with ESMTP id 770FC4437C for ; Mon, 3 Jul 2000 17:11:41 -0400 (EDT) Received: from MATT.ascend.com (ts022d25.lap-ca.concentric.net [64.1.213.85]) by marlborough.cnchost.com id RAA16818; Mon, 3 Jul 2000 17:08:16 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-Id: <4.3.1.2.20000703135959.00b98ee0@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 03 Jul 2000 14:06:23 -0700 To: Henry Sinnreich From: Matt Holdrege Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) Cc: "'Neil Deason'" , "Gardell, Steve" , sip@lists.bell-labs.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 02:47 PM 7/3/00 -0500, Henry Sinnreich wrote: >Problems seem to arise when circuit switch vendors promote the >softswitch as an "exterior" service platform, across the net. >Even without going into the technical issues, it seems we would >then end up with a "Softswitchnet" instead of the Internet. This >seemed far fetched to me until I actually heard a circuit switch >vendor promoting the "Next Generation Public Network" that >actually went so far as to discard the Internet completely! There is nothing we can do about vendor marketing approaches here. >More problems arise when a GC is promoted to control IP phones. >In this case, a competitor to the operator for that GC could not >extend features to the GC controlled phones. This is a prime >example of fogging up the Internet, actually of reinventing >unequal access at the control level. Besides, how do you >integrate the services of xGCP phones with other services on the >Internet? There is nothing we can do about competitive control of phones or services here. All we can do is build protocols. How they are used in the above context is way outside our scope. >The above may be mistaken opinions, but there are also questions >such as, how does a softswitch environment handle: >Presence? >Instant Messaging? >Unified Messaging? >Caller and called preferences? >Mobility? The Softswitch could incorporate each of those features. But the more likely scenario is that they would use SIP to communicate to ASP's that provide those features. A SIP phone may not need a softswitch to do this, but the umpteen billion non-SIP phones need a little help. This style of open service delivery is one of the great things about our next-gen architecture. >Some time ago, SIP and H.323 comparisons were made in a number >of places. Is it now time to make SIP-softswitch comparisons? SIP and Softswitches are not mutually exclusive. Pretty much all Softswitches speak SIP now or will in the near future. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 3 17:14:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07751 for ; Mon, 3 Jul 2000 17:14:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF9EC4438B; Mon, 3 Jul 2000 17:14:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from marlborough.cnchost.com (marlborough.concentric.net [207.155.248.14]) by lists.bell-labs.com (Postfix) with ESMTP id C0E8F4437E for ; Mon, 3 Jul 2000 17:14:04 -0400 (EDT) Received: from MATT.ascend.com (ts022d25.lap-ca.concentric.net [64.1.213.85]) by marlborough.cnchost.com id RAA19494; Mon, 3 Jul 2000 17:14:01 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-Id: <4.3.1.2.20000703141347.00bd8d20@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 03 Jul 2000 14:15:34 -0700 To: "Neville O'reilly" From: Matt Holdrege Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) Cc: sip@lists.bell-labs.com In-Reply-To: <6C5713970B1FD411ACBE00AA00DCD9A6098506@crash.engineering.n etspeak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 05:02 PM 7/3/00 -0400, Neville O'reilly wrote: >1) I did not know "Verizon" was a company - yet (although the Genuity IPO >seems to remove the last major obstacle.) According to the Ultimate Authority (Wall St.) VZ was born today. >2) the term "softswitch" does not denote a switch - is it not most often >used for a call control and processing agent (Call Agent , MGC are pretty >syonomous terms? - a term that came about in the context of the adoption of >a 3 layer "architecture" which separates services, call control and >infrastructure/gateways from each other. It has nothing to do intrinsically >with end user controlled vs. network controlled services. Yep! >SOftswitch implementations could range from consumer software distributed on >a CD to network centric call processors which manage large mediation >switches and MGs with high port densities through MGCP signalling and talk >to each other via SIP - for example. Precisely! And they can talk to ASP's via 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 Jul 4 04:07:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25716 for ; Tue, 4 Jul 2000 04:07:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FEEB4436B; Tue, 4 Jul 2000 04:06:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id E34A644336 for ; Tue, 4 Jul 2000 04:06:08 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e647xIs20863; Tue, 4 Jul 2000 09:59:19 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA09621; Tue, 4 Jul 2000 10:59:17 +0300 (EET DST) Message-ID: <3961992B.793643F7@lmf.ericsson.se> Date: Tue, 04 Jul 2000 10:58:35 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip , schulzrinne@cs.columbia.edu, jdrosen@dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] QoS & Third Party Call Control in SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, The draft "Third Party Call Control in SIP", which can be found at http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt outlines a method for establishing a session between two hosts that have signalling (SIP) relationships with a 3rd host that is not involved in the session. The idea is basically to send an INVITE to A-party without SDP and then send the SDP coming from the B-party in the ACK. This works fine when no QoS is needed. If preconditions must be used this method fails. Preconditions cannot be added to the SDP in the ACK, since ACKs trigger no responses. Both parties involved in the session have to know both SDP descriptions in order to perform resource reservation (with RSVP, for instance). Then, COMET will have to be sent. Have somebody taken this into account regarding this draft? Any ideas? 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 04:20:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25753 for ; Tue, 4 Jul 2000 04:20:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1586F44374; Tue, 4 Jul 2000 04:20:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id AE38844336 for ; Tue, 4 Jul 2000 04:20:05 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id NAA28981 for ; Tue, 4 Jul 2000 13:49:03 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Tue, 04 Jul 2000 13:49:01 +0000 (IST) Received: from localhost (chandra@localhost) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id NAA21187 for ; Tue, 4 Jul 2000 13:49:00 +0530 (IST) Date: Tue, 4 Jul 2000 13:48:59 +0530 (IST) From: Sarat Chandran To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] On PGP Itself.. (Non Technical) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I think PGP is a licensed encryption scheme. Can anybody please explain the process to be followed, while it is being used in a commercial implementation of SIP. (I did not want to send this to a group where normally technical topics are discussed, but I did not get a reply when I contacted the customer-service section of NAI Labs) Thanks Sarat Sarat Chandran P K Silicon Automation Systems Bangalore - 8, India _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 04:47:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25857 for ; Tue, 4 Jul 2000 04:47:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37A074436D; Tue, 4 Jul 2000 04:47:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 77D0244336 for ; Tue, 4 Jul 2000 04:47:30 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA29050; Tue, 4 Jul 2000 09:45:34 +0100 (BST) Message-ID: <3961A42F.BF3E42EC@ubiquity.net> Date: Tue, 04 Jul 2000 09:45:35 +0100 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: "Gardell, Steve" Cc: "'Henry Sinnreich'" , "'sip@lists.bell-labs.com'" Subject: Re: Softswitches (was Re: [SIP] SIP->XML->SOAP) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Gardell, Steve" wrote: > > Thanks for the pointer Neil. > > Given current market-driven definitions, Henry's > description (definition) of softswitches is > reasonable, but I would note that a number > of vendors talk of using "softswitches" in > contexts where there is no (direct) SS7 > signaling. For example one leading telcom > vendor used a "softswitch" as a foundation > for a new IP-PBX. Also, "softswitches" are promoted as > "interior" service platforms (e.g. not controlling > any MG's) by several large telcom vendors. > > SIP is a wonderful tool for service creation in > it's own right, but I don't think that Henry's article > really does justice to "API approaches" to service > creation and standardization such as JAIN/JTAPI. > At the least a reasoned discounting might be in > order. A problem with these APIs tends to be the lack of support for them. JTAPI must be about 4 years old now and how many implementations of it are there? It is nice for Sun to define the Java interfaces for just about everything, but everybody else has to be convinced to go and actually implement them. As JAIN appears to want to be the mother of all telecom interfaces we will have to wait to see what happens there. But I can't recall seeing much progress over the last year from JAIN. Maybe someone from Dynamicsoft has a better perspective on the situation as they are leading the JAIN-SIP initiative? Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > Lastly, in a heterogeneous world order (where it > just ain't all IP), it seems to me that softswitches > are a step in the right direction, especially if > we allow that it is a "poor softswitch that is > not also a SIP Proxy." As a representative of the > company (Verizon) with the largest number of POTS > lines in the US, I am not sure what choice I have... > > > Steven Gardell > GTE Laboratories > Voice: 781-466-2681, Fax: 781-466-3375 > > > -----Original Message----- [snip] _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 09:15:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27732 for ; Tue, 4 Jul 2000 09:15:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0868D44350; Tue, 4 Jul 2000 09:15:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id B7D9844336 for ; Tue, 4 Jul 2000 09:14:52 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA24958; Tue, 4 Jul 2000 14:12:26 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Henning Schulzrinne Subject: Re: [SIP] SIP URL telephone-subscriber syntax. Date: Tue, 4 Jul 2000 13:33:18 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com References: <00070312353001.26755@gethin> <3960B5B9.6E609F5F@cs.columbia.edu> In-Reply-To: <3960B5B9.6E609F5F@cs.columbia.edu> MIME-Version: 1.0 Message-Id: <00070414064101.27308@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Mon, 03 Jul 2000, Henning Schulzrinne wrote: > Therefore, I'd suggest that either all tel URL "meta" characters (? and > semicolon, I believe) are valid in the user part or that these parts are > "exported" to the end of the SIP URL. The latter idea is ugly, but at > least syntactically workable. My preference is to allow ; and ? in > user-info, but none of the three solutions is blessed by aesthetics, so > I'm largely agnostic as long as somebody can produce a simple, > unambiguous description of the mechanism. > OK, I can see no problem with allowing `;' and `?' in the user part. All other invalid characters have to be escaped. This only actually works however, because `;' and `?' are delimiters within telephone-subscriber but not within userinfo. If, for example, `:' had an actual meaning within telephone-subscriber (as it does in userinfo) then we would be in with a problem. Note, i'm not complaining, just noting that i think we got of lightly :) As for the description, are there any arguments/problems/discrepencies with the following: #1) Amend user in the bnf user = *( unreserved | escaped | & | = | + | $ | , | ; | ? ) #2) Add text to the effect of the following in section 2 under the telephone-subscriber part: "Any characters of the un-escaped `telephone-subscriber' that do not exist in the character set of `user' MUST be escaped. Because the `telephone-subscriber' reserved characters set is a subset of the `user' reserved characters set, a correct `telephone-subscriber' syntax is maintained." I think that suffices, if a bit flowery :) -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 11:45:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28555 for ; Tue, 4 Jul 2000 11:45:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5BB094433C; Tue, 4 Jul 2000 11:45:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by lists.bell-labs.com (Postfix) with ESMTP id 50B9344336 for ; Tue, 4 Jul 2000 11:44:58 -0400 (EDT) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id LAA07949 for ; Tue, 4 Jul 2000 11:38:13 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdDAAsRNbi_; Tue Jul 4 11:38:10 2000 Received: from kong.starvision.com by kanata-mh1.ca.newbridge.com with ESMTP for sip@lists.bell-labs.com; Tue, 4 Jul 2000 11:44:46 -0400 Received: from starvision.com (lion [192.168.208.171]) by starvision.com (8.8.8+Sun/8.8.8) with ESMTP id IAA08448 for ; Tue, 4 Jul 2000 08:44:57 -0700 (PDT) Message-Id: <396205A3.293EB914@starvision.com> Date: Tue, 04 Jul 2000 08:41:23 -0700 From: Serban Tatu Organization: Starvision Multimedia X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en,ro MIME-Version: 1.0 To: siplist Content-Type: multipart/mixed; boundary="------------0123C8A90DB83341747EA681" Subject: [SIP] SIP-speaking gateway Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------0123C8A90DB83341747EA681 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Does anyone know of any SIP-enabled gateway that is actually capable of playing media carried by SIP messages? (e.g. audio files containing ads or voice prompts). Thanks, Serban --------------0123C8A90DB83341747EA681 Content-Type: text/x-vcard; charset=us-ascii; name="statu.vcf" Content-Description: Card for Serban Tatu Content-Disposition: attachment; filename="statu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Tatu;Serban tel;fax:(604)918-6400 tel;work:(604)918-6382 x-mozilla-html:FALSE org:Starvision Multimedia Corp. adr:;;4190 Still Creek Drive;Vancouver;BC ;V5C 6C6;Canada version:2.1 email;internet:statu@starvision.com title:Software Developer note:http://www.starvision.com/ x-mozilla-cpt:;-3776 fn:Serban Tatu end:vcard --------------0123C8A90DB83341747EA681-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 11:59:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28611 for ; Tue, 4 Jul 2000 11:59:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F47344356; Tue, 4 Jul 2000 11:59:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id A818B44352 for ; Tue, 4 Jul 2000 11:59:21 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FX600101KEWIQ@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 4 Jul 2000 15:59:20 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FX600H54KEWJ6@firewall.mcit.com>; Tue, 04 Jul 2000 15:59:20 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FX600001KD7B9@dgismtp03.wcomnet.com>; Tue, 04 Jul 2000 15:58:19 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FX600001KD67G@dgismtp03.wcomnet.com>; Tue, 04 Jul 2000 15:58:19 +0000 (GMT) Received: from C25776A ([166.44.137.23]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FX600EISKCOZ7@dgismtp03.wcomnet.com>; Tue, 04 Jul 2000 15:58:03 +0000 (GMT) Date: Tue, 04 Jul 2000 10:58:34 -0500 From: Henry Sinnreich Subject: RE: [SIP] SIP-speaking gateway In-reply-to: <396205A3.293EB914@starvision.com> To: Serban Tatu , siplist Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >Does anyone know of any SIP-enabled gateway that is >actually capable of playing >media carried by SIP messages? Suggest to get in touch with 3Com folks. They may be one of those who are close to it, I believe. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Serban Tatu >Sent: Tuesday, July 04, 2000 10:41 AM >To: siplist >Subject: [SIP] SIP-speaking gateway > > >Hi, > >Does anyone know of any SIP-enabled gateway that is >actually capable of playing >media carried by SIP messages? (e.g. audio files >containing ads or voice >prompts). > >Thanks, >Serban > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 12:13:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28734 for ; Tue, 4 Jul 2000 12:13:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4B4F24433C; Tue, 4 Jul 2000 12:13:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id E759744336 for ; Tue, 4 Jul 2000 12:13:12 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FX600801L20QZ@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 4 Jul 2000 16:13:12 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FX60071NL20DW@firewall.mcit.com>; Tue, 04 Jul 2000 16:13:12 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0FX600501L0A6B@dgismtp03.wcomnet.com>; Tue, 04 Jul 2000 16:12:10 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FX600501L0922@dgismtp03.wcomnet.com>; Tue, 04 Jul 2000 16:12:10 +0000 (GMT) Received: from C25776A ([166.44.137.23]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FX600ELTKZRZ5@dgismtp03.wcomnet.com>; Tue, 04 Jul 2000 16:11:56 +0000 (GMT) Date: Tue, 04 Jul 2000 11:12:25 -0500 From: Henry Sinnreich Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) In-reply-to: <4.3.1.2.20000703135959.00b98ee0@pop3.ipverse.com> To: Matt Holdrege Cc: "'Neil Deason'" , "Gardell, Steve" , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Matt, thanks for the reasoned note. One item: >A SIP phone may not need a >softswitch to do this, >but the umpteen billion non-SIP phones need a little help. SIP RJ-11 to RJ-45 adapters are now available and could be available as consumer devices with consumer price points. Such adapters are actually one-channel IP telephony gateways and are fully qualified SIP UAs under user control. Compliant with Internet transparency. Personally, I would always prefer a SIP Ethernet to black phone adapter that gives me free choice of service provider to xGCP phones controlled by the Telco as in old times. Would you really have your analog phones controlled by the Telco, rather then being able to point them to any SIP server of your choice? Henry >-----Original Message----- >From: Matt Holdrege [mailto:matt@ipverse.com] >Sent: Monday, July 03, 2000 4:06 PM >To: Henry Sinnreich >Cc: 'Neil Deason'; Gardell, Steve; sip@lists.bell-labs.com >Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) > > >At 02:47 PM 7/3/00 -0500, Henry Sinnreich wrote: >>Problems seem to arise when circuit switch vendors promote the >>softswitch as an "exterior" service platform, across the net. >>Even without going into the technical issues, it >seems we would >>then end up with a "Softswitchnet" instead of the >Internet. This >>seemed far fetched to me until I actually heard a >circuit switch >>vendor promoting the "Next Generation Public Network" that >>actually went so far as to discard the Internet completely! > >There is nothing we can do about vendor marketing >approaches here. > >>More problems arise when a GC is promoted to control >IP phones. >>In this case, a competitor to the operator for that >GC could not >>extend features to the GC controlled phones. This is a prime >>example of fogging up the Internet, actually of reinventing >>unequal access at the control level. Besides, how do you >>integrate the services of xGCP phones with other >services on the >>Internet? > >There is nothing we can do about competitive control >of phones or services >here. All we can do is build protocols. How they are >used in the above >context is way outside our scope. > >>The above may be mistaken opinions, but there are >also questions >>such as, how does a softswitch environment handle: >>Presence? >>Instant Messaging? >>Unified Messaging? >>Caller and called preferences? >>Mobility? > >The Softswitch could incorporate each of those >features. But the more >likely scenario is that they would use SIP to >communicate to ASP's that >provide those features. A SIP phone may not need a >softswitch to do this, >but the umpteen billion non-SIP phones need a little help. > >This style of open service delivery is one of the >great things about our >next-gen architecture. > >>Some time ago, SIP and H.323 comparisons were made in a number >>of places. Is it now time to make SIP-softswitch comparisons? > >SIP and Softswitches are not mutually exclusive. >Pretty much all >Softswitches speak SIP now or will in the near future. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 12:47:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29010 for ; Tue, 4 Jul 2000 12:47:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6FD4C4435D; Tue, 4 Jul 2000 12:46:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by lists.bell-labs.com (Postfix) with ESMTP id BE54B44352 for ; Tue, 4 Jul 2000 12:46:51 -0400 (EDT) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id MAA14390 for ; Tue, 4 Jul 2000 12:40:08 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdBAA0cP_Qp; Tue Jul 4 12:40:00 2000 Received: from kong.starvision.com by kanata-mh1.ca.newbridge.com with ESMTP for sip@lists.bell-labs.com; Tue, 4 Jul 2000 12:45:42 -0400 Received: from starvision.com (lion [192.168.208.171]) by starvision.com (8.8.8+Sun/8.8.8) with ESMTP id JAA10155 for ; Tue, 4 Jul 2000 09:45:53 -0700 (PDT) Message-Id: <396213EB.C59009FC@starvision.com> Date: Tue, 04 Jul 2000 09:42:19 -0700 From: Serban Tatu Organization: Starvision Multimedia X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en,ro MIME-Version: 1.0 To: siplist Content-Type: multipart/mixed; boundary="------------D7B89AEB8B441A5F0704A8E9" Subject: [SIP] authentication at gateway Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------D7B89AEB8B441A5F0704A8E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, How is authentication performed by a SIP-enabled gateway? Let's say somebody on a PSTN phone wants to gain access to a service and therefore has to provide a username/password. Some scenarios come to mind (newbie here): Scenario 1 (smart gateway): - SIP UAS at service side sends a 401 unauthorized as a response to the INVITE. The response contains a voice prompt audio file (e.g. Gimme username/password). - gateway is so smart that it knows how to play the prompt and collect DTMF tones representing username and password, which it then sends back encoded somehow to the service. Scenario 2 (not so smart gateway): - SIP UAS at service side sends back a 200 OK response to the INVITE. The response contains the voice prompt as before. - gateway knows how to play the audio file, sends ACK, media connections are open. - SIP UAS at service side then sends an INFO message with a DTMF collection scheme (voice prompt could also be sent here). - gateway collects the tones and sends them back with another INFO message. Scenario 3 (dumb gateway): - SIP UAS at service side sends back a 200 OK response to the INVITE. - gateway and SIP UAS establish their media channels. - service then plays the whole authentication scenario through the media channels. Gateway lets DTMF tones flow through the media path. Do any of these scenarios make any sense? It seems to me that 1 and 2 are sci-fi given the current gateway solutions, while 3 might not be possible because the gateway grabs the DTMF tones, or if it doesn't then it's an ugly solution since signaling and media are all mixed together. Thanks, Serban --------------D7B89AEB8B441A5F0704A8E9 Content-Type: text/x-vcard; charset=us-ascii; name="statu.vcf" Content-Description: Card for Serban Tatu Content-Disposition: attachment; filename="statu.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Tatu;Serban tel;fax:(604)918-6400 tel;work:(604)918-6382 x-mozilla-html:FALSE org:Starvision Multimedia Corp. adr:;;4190 Still Creek Drive;Vancouver;BC ;V5C 6C6;Canada version:2.1 email;internet:statu@starvision.com title:Software Developer note:http://www.starvision.com/ x-mozilla-cpt:;-3776 fn:Serban Tatu end:vcard --------------D7B89AEB8B441A5F0704A8E9-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 13:29:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29321 for ; Tue, 4 Jul 2000 13:29:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E4AE844365; Tue, 4 Jul 2000 13:29:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by lists.bell-labs.com (Postfix) with ESMTP id E542D44336 for ; Tue, 4 Jul 2000 13:29:03 -0400 (EDT) Received: from MATT.ascend.com (ts018d08.lap-ca.concentric.net [64.1.210.116]) by wellington.cnchost.com id NAA13954; Tue, 4 Jul 2000 13:29:01 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-Id: <4.3.1.2.20000704083129.00c4e820@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 04 Jul 2000 08:35:13 -0700 To: Henry Sinnreich From: Matt Holdrege Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) Cc: sip@lists.bell-labs.com In-Reply-To: References: <4.3.1.2.20000703135959.00b98ee0@pop3.ipverse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 11:12 AM 7/4/00 -0500, Henry Sinnreich wrote: >Matt, thanks for the reasoned note. One item: > >A SIP phone may not need a > >softswitch to do this, > >but the umpteen billion non-SIP phones need a little help. > >SIP RJ-11 to RJ-45 adapters are now available and could be >available as consumer devices with consumer price points. Such >adapters are actually one-channel IP telephony gateways and are >fully qualified SIP UAs under user control. Compliant with >Internet transparency. Personally, I would always prefer a SIP >Ethernet to black phone adapter that gives me free choice of >service provider to xGCP phones controlled by the Telco as in >old times. Would you really have your analog phones controlled >by the Telco, rather then being able to point them to any SIP >server of your choice? Sure, but I think it may be a few years before everyone in the world has such a phone which is why we need to help them into a more open architecture. Even with XGCP controlled phones, things are way more open than with the circuit-switched world. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 15: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 ESMTP id PAA00364 for ; Tue, 4 Jul 2000 15:51:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 559DC44368; Tue, 4 Jul 2000 15:50:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 9E6F344336 for ; Tue, 4 Jul 2000 15:50:45 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA03418; Tue, 4 Jul 2000 15:50:40 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA19207; Tue, 4 Jul 2000 15:50:39 -0400 (EDT) Message-ID: <3962400F.127C6862@cs.columbia.edu> Date: Tue, 04 Jul 2000 15:50:39 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: sip@lists.bell-labs.com, antti.vaha-sipila@nokia.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: <00070312353001.26755@gethin> <3960B5B9.6E609F5F@cs.columbia.edu> <00070414064101.27308@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Modified spec roughly accordingly. Note that RFC 2806 has a mistake in that % can never appear as itself. Same for %22 (") and %23 (#), %3c (<) and %3e (>), according to RFC 2396. I would suggest this be fixed in RFC2806bis. Also, the tel: URL allows various characters that RFC 2396 declares "unwise" and thus MUST be escaped. [Note that any character can be used if escaped, so characters only need to be listed explicitly if they are safe if used by themself, without escaping. 2806 seems to not follow this convention.] -- 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 Jul 4 20:50:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01767 for ; Tue, 4 Jul 2000 20:50:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F34944352; Tue, 4 Jul 2000 20:50:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 25BDF44336 for ; Tue, 4 Jul 2000 20:50:01 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jul 2000 17:51:01 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Gethin Liddell'" , Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Tue, 4 Jul 2000 17:50:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com You will also have to require that the user part cannot be empty if the user part contains semicolons or question marks. sip:ACDC;dog=cat sip:ACDC;dog=cat@ACDC;user=phone Robert. > -----Original Message----- > From: Gethin Liddell [mailto:gethin@ubiquity.net] > Sent: Tuesday, July 04, 2000 8:33 PM > To: Henning Schulzrinne > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP URL telephone-subscriber syntax. > > > On Mon, 03 Jul 2000, Henning Schulzrinne wrote: > > Therefore, I'd suggest that either all tel URL "meta" > characters (? and > > semicolon, I believe) are valid in the user part or that > these parts are > > "exported" to the end of the SIP URL. The latter idea is > ugly, but at > > least syntactically workable. My preference is to allow ; and ? in > > user-info, but none of the three solutions is blessed by > aesthetics, so > > I'm largely agnostic as long as somebody can produce a simple, > > unambiguous description of the mechanism. > > > > OK, I can see no problem with allowing `;' and `?' in the user part. > All other invalid characters have to be escaped. > > This only actually works however, because `;' and `?' are delimiters > within telephone-subscriber but not within userinfo. If, for example, > `:' had an actual meaning within telephone-subscriber (as it does > in userinfo) then we would be in with a problem. > > Note, i'm not complaining, just noting that i think we got of > lightly :) > > As for the description, are there any arguments/problems/discrepencies > with the following: > > #1) Amend user in the bnf > user = *( unreserved | escaped | & | = | + | $ | , | > ; | ? ) > > #2) Add text to the effect of the following in section 2 under the > telephone-subscriber part: > > "Any characters of the un-escaped `telephone-subscriber' that do not > exist in the character set of `user' MUST be escaped. Because the > `telephone-subscriber' reserved characters set is a subset of > the `user' > reserved characters set, a correct `telephone-subscriber' syntax is > maintained." > > I think that suffices, if a bit flowery :) > > -- > 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 Tue Jul 4 20:58:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01788 for ; Tue, 4 Jul 2000 20:58:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC3E944368; Tue, 4 Jul 2000 20:58:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 4434F4435E for ; Tue, 4 Jul 2000 20:58:51 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jul 2000 17:59:52 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Gethin Liddell'" , Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Tue, 4 Jul 2000 17:59:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Sorry, brain fart. Disregard last email. If the user part is empty - there can't be any semicolons. :) Where's that coffee pot. Robert. > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Wednesday, July 05, 2000 8:51 AM > To: 'Gethin Liddell'; Henning Schulzrinne > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP URL telephone-subscriber syntax. > > > You will also have to require that the user part cannot be > empty if the user > part contains semicolons or question marks. > > sip:ACDC;dog=cat > sip:ACDC;dog=cat@ACDC;user=phone > > Robert. > > > -----Original Message----- > > From: Gethin Liddell [mailto:gethin@ubiquity.net] > > Sent: Tuesday, July 04, 2000 8:33 PM > > To: Henning Schulzrinne > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] SIP URL telephone-subscriber syntax. > > > > > > On Mon, 03 Jul 2000, Henning Schulzrinne wrote: > > > Therefore, I'd suggest that either all tel URL "meta" > > characters (? and > > > semicolon, I believe) are valid in the user part or that > > these parts are > > > "exported" to the end of the SIP URL. The latter idea is > > ugly, but at > > > least syntactically workable. My preference is to allow ; and ? in > > > user-info, but none of the three solutions is blessed by > > aesthetics, so > > > I'm largely agnostic as long as somebody can produce a simple, > > > unambiguous description of the mechanism. > > > > > > > OK, I can see no problem with allowing `;' and `?' in the user part. > > All other invalid characters have to be escaped. > > > > This only actually works however, because `;' and `?' are delimiters > > within telephone-subscriber but not within userinfo. If, > for example, > > `:' had an actual meaning within telephone-subscriber (as it does > > in userinfo) then we would be in with a problem. > > > > Note, i'm not complaining, just noting that i think we got of > > lightly :) > > > > As for the description, are there any > arguments/problems/discrepencies > > with the following: > > > > #1) Amend user in the bnf > > user = *( unreserved | escaped | & | = | + | $ | , | > > ; | ? ) > > > > #2) Add text to the effect of the following in section 2 under the > > telephone-subscriber part: > > > > "Any characters of the un-escaped `telephone-subscriber' that do not > > exist in the character set of `user' MUST be escaped. Because the > > `telephone-subscriber' reserved characters set is a subset of > > the `user' > > reserved characters set, a correct `telephone-subscriber' syntax is > > maintained." > > > > I think that suffices, if a bit flowery :) > > > > -- > > 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 Tue Jul 4 23:31:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04772 for ; Tue, 4 Jul 2000 23:31:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1EA834435E; Tue, 4 Jul 2000 23:30:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 1672644346 for ; Tue, 4 Jul 2000 23:30:30 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jul 2000 20:31:31 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Gethin Liddell'" , Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Tue, 4 Jul 2000 20:31:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The point I was really trying to make is that allowing semicolons and question marks in the user part will cause problems with existing server parsers that treat the semicolon as a delimiter to the user@host:port part or don't support the user=phone parameter. For instance, if the parser doesn't support user=phone: sip:ABCD;dog=cat@fish.com;user=phone will be treated as hostname ABCD with a paramter dog=cat@fish.com (rather than some uninterpreted user name at fish.com). If the parser determines the end of the user@host:port by searching for a semicolon then the same thing will occur. This is a valid (as far as I can see) and simple way for parser to pull out the base URL (until now). Slightly kludgier but at least syntactically workable would be to differently quote the meta characters in the tel:. For example a semicolon in the tel would be written as %%3b. Now the you can diffentiate %3b from %%3b - ok so its a hack but it should work nicely. "Any characters of the _escaped_ `telephone-subscriber' [per RFC2396] that do not exist in the character set of `user' MUST be escaped using two percentage marks followed by the character hex value. " For example: Unescaped: tel:ABCD;dog="cat litter"?stuff Escaped: tel:ABCD;dog=%22cat%20litter%22?stuff would become sip:ABCD%%3bdog=%22cat%20litter%22%%3fstuff@fish.com;user=phone I would rather a kludge that works nicely than changing the characters allowable in the user part which further complicates the parsing of a sip URL. Your suggestion would mean you can only parse a URI correctly by _first_ locating and understanding one of the parameters !!! Right? Robert. > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Wednesday, July 05, 2000 9:00 AM > To: 'Gethin Liddell'; Henning Schulzrinne > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP URL telephone-subscriber syntax. > > > Sorry, brain fart. > > Disregard last email. If the user part is empty - there can't be any > semicolons. :) > > Where's that coffee pot. > > Robert. > > > -----Original Message----- > > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > Sent: Wednesday, July 05, 2000 8:51 AM > > To: 'Gethin Liddell'; Henning Schulzrinne > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] SIP URL telephone-subscriber syntax. > > > > > > You will also have to require that the user part cannot be > > empty if the user > > part contains semicolons or question marks. > > > > sip:ACDC;dog=cat > > sip:ACDC;dog=cat@ACDC;user=phone > > > > Robert. > > > > > -----Original Message----- > > > From: Gethin Liddell [mailto:gethin@ubiquity.net] > > > Sent: Tuesday, July 04, 2000 8:33 PM > > > To: Henning Schulzrinne > > > Cc: sip@lists.bell-labs.com > > > Subject: Re: [SIP] SIP URL telephone-subscriber syntax. > > > > > > > > > On Mon, 03 Jul 2000, Henning Schulzrinne wrote: > > > > Therefore, I'd suggest that either all tel URL "meta" > > > characters (? and > > > > semicolon, I believe) are valid in the user part or that > > > these parts are > > > > "exported" to the end of the SIP URL. The latter idea is > > > ugly, but at > > > > least syntactically workable. My preference is to allow > ; and ? in > > > > user-info, but none of the three solutions is blessed by > > > aesthetics, so > > > > I'm largely agnostic as long as somebody can produce a simple, > > > > unambiguous description of the mechanism. > > > > > > > > > > OK, I can see no problem with allowing `;' and `?' in the > user part. > > > All other invalid characters have to be escaped. > > > > > > This only actually works however, because `;' and `?' are > delimiters > > > within telephone-subscriber but not within userinfo. If, > > for example, > > > `:' had an actual meaning within telephone-subscriber (as it does > > > in userinfo) then we would be in with a problem. > > > > > > Note, i'm not complaining, just noting that i think we got of > > > lightly :) > > > > > > As for the description, are there any > > arguments/problems/discrepencies > > > with the following: > > > > > > #1) Amend user in the bnf > > > user = *( unreserved | escaped | & | = | + | $ | , | > > > ; | ? ) > > > > > > #2) Add text to the effect of the following in section 2 under the > > > telephone-subscriber part: > > > > > > "Any characters of the un-escaped `telephone-subscriber' > that do not > > > exist in the character set of `user' MUST be escaped. Because the > > > `telephone-subscriber' reserved characters set is a subset of > > > the `user' > > > reserved characters set, a correct `telephone-subscriber' > syntax is > > > maintained." > > > > > > I think that suffices, if a bit flowery :) > > > > > > -- > > > 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 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 4 23: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 ESMTP id XAA04978 for ; Tue, 4 Jul 2000 23:59:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B5DD644351; Tue, 4 Jul 2000 23:58:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5FF5E44346 for ; Tue, 4 Jul 2000 23:58:52 -0400 (EDT) Received: from dynamicsoft.com (1Cust211.tnt4.freehold.nj.da.uu.net [63.36.112.211]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02233; Wed, 5 Jul 2000 00:00:09 -0400 (EDT) Message-ID: <3962B309.2478396F@dynamicsoft.com> Date: Wed, 05 Jul 2000 00:01:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Serban Tatu Cc: siplist Subject: Re: [SIP] authentication at gateway References: <396213EB.C59009FC@starvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit THe most likely scenario is one you left out: the prompting and collection for the PIN are all performed by the originating gateway. In general, the entity demanding authentication will not know that the request is through a gateway. I believe its unlikely the entity would return 200 OK, or even a 401 with content. Rather, just a 401. So, upon receiving the 401, the gateway performs some local operation to get the username and password. Perhaps it plays out an announcement and collects the username/password; perhaps they are simply established ahead of time and stored in a database - the gateway just fetches them when prompted for authentication. -Jonathan R. Serban Tatu wrote: > > Hi, > > How is authentication performed by a SIP-enabled gateway? Let's say somebody on > a PSTN phone wants to gain access to a service and therefore has to provide a > username/password. Some scenarios come to mind (newbie > here): > > Scenario 1 (smart gateway): > > - SIP UAS at service side sends a 401 unauthorized as a response to the INVITE. > The response contains a voice prompt audio file (e.g. Gimme > username/password). > - gateway is so smart that it knows how to play the prompt and collect DTMF > tones representing username and password, which it then sends back encoded > somehow to the service. > > Scenario 2 (not so smart gateway): > > - SIP UAS at service side sends back a 200 OK response to the INVITE. The > response contains the voice prompt as before. > - gateway knows how to play the audio file, sends ACK, media connections are > open. > - SIP UAS at service side then sends an INFO message with a DTMF collection > scheme (voice prompt could also be sent here). > - gateway collects the tones and sends them back with another INFO message. > > Scenario 3 (dumb gateway): > > - SIP UAS at service side sends back a 200 OK response to the INVITE. > - gateway and SIP UAS establish their media channels. > - service then plays the whole authentication scenario through the media > channels. Gateway lets DTMF tones flow through the media path. > > Do any of these scenarios make any sense? It seems to me that 1 and 2 are sci-fi > given the current gateway solutions, while 3 might not be possible because the > gateway grabs the DTMF tones, or if it doesn't then it's an ugly solution since > signaling and media are all mixed together. > > Thanks, > Serban -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 00:10:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05087 for ; Wed, 5 Jul 2000 00:10:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2E6144374; Wed, 5 Jul 2000 00:09:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5B46144369 for ; Wed, 5 Jul 2000 00:09:31 -0400 (EDT) Received: from dynamicsoft.com (1Cust211.tnt4.freehold.nj.da.uu.net [63.36.112.211]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02274; Wed, 5 Jul 2000 00:10:37 -0400 (EDT) Message-ID: <3962B57D.16E4FCAC@dynamicsoft.com> Date: Wed, 05 Jul 2000 00:11:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Pathangi N Janardhanan , sip@lists.bell-labs.com Subject: Re: [SIP] few questions References: <200006291657.LAA10490@b04a45.exu.ericsson.se> <395D6FE1.D0D7EFC8@dynamicsoft.com> <005c01bfe329$d97d6020$38c9a8c0@labs> <395E62A4.4EA8D296@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > > b) Are there any requirements for scripts that the server must > > support, say CLP, XML > > etc? i.e. is there a minimum set that any server must understand? > > No. It all depends on what services you want to provide to your > customers. > > > Is there any way for a client to know of this capability? > > Why would it want to know? Script execution is transparent to user > agents. If a user wants to upload a CPL to a server in a REGISTER, it can simply try and if it fails with a 415 Unsupported Media, listing the type for CPL, you know its not supported. If you want to discover a proxy server that supports CPL, for example, you can use the Service Location Protocol (SLP). We have recently registered templates for discovering SIP servers based on capabilities. Check out: http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/sip.1.0.en http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/sipproxy.1.0.en http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/sipregistrar.1.0.en 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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 00:16:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05111 for ; Wed, 5 Jul 2000 00:16:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D45F74436D; Wed, 5 Jul 2000 00:16:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 176B444352 for ; Wed, 5 Jul 2000 00:16:17 -0400 (EDT) Received: from dynamicsoft.com (1Cust211.tnt4.freehold.nj.da.uu.net [63.36.112.211]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02298; Wed, 5 Jul 2000 00:17:31 -0400 (EDT) Message-ID: <3962B71A.62941794@dynamicsoft.com> Date: Wed, 05 Jul 2000 00:18:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Sean Olson , Adam.Roach@Ericsson.com, rohan@cisco.com, oran@cisco.com, rfairlie@nuera.com, sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006291657.LAA10490@b04a45.exu.ericsson.se> <395D6FE1.D0D7EFC8@dynamicsoft.com> <395DF21E.BC68B052@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I agree. > > > > The only semantic difference between a header vs. a purpose parameter > > is, as I and Adam pointed out, handling of unknown purposes. With a > > header, they are discarded. With a parameter, the policy of the UA could > > discard them or render them at its discretion. Since syntactic arguments > > are fundamentally futile, I think it is useful to make a decision based > > on the semantic differences. I prefer the more generally useful approach > > of using the parameter. > > > > > I agree, but would tend to view semantic equivalence as somewhat more > limited. For example, I don't think that error indication, ringing > indication and additional information about caller/callee can just all > be rendered if I don't recognize the purpose tag. This is the big issue. My proposal is that this header be ONLY for things which can be reasonably rendered without knowing the semantic content. I think this includes things like jpeg/vcards for caller ID, for example, but not distinctive ringing, as you point out. As an example, if a > client doesn't know about distinctive ringing, just rendering the > header-indicated sound and local ringing at the same time is probably > less than ideal. In the end, I don't think header vs. parameters doesn't > matter all that much, so maybe it is more useful to gather applications > for this: > > - ringing > - caller/callee web page > - caller/callee iconic/avatar representation (e.g., a small JPEG or GIF) > - possibly error indication > > Anything else? caller addrres information - vcard FYI web content (BYE can contain a URL which points to a web page discussed during the call) -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 00:19:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05129 for ; Wed, 5 Jul 2000 00:19:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D106A44389; Wed, 5 Jul 2000 00:18:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 425D84437E for ; Wed, 5 Jul 2000 00:18:18 -0400 (EDT) Received: from dynamicsoft.com (1Cust211.tnt4.freehold.nj.da.uu.net [63.36.112.211]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02307; Wed, 5 Jul 2000 00:19:45 -0400 (EDT) Message-ID: <3962B7A0.76F0EA53@dynamicsoft.com> Date: Wed, 05 Jul 2000 00:20:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Shail Bhatnagar , sip@lists.bell-labs.com Subject: Re: [SIP] "Legal" redirect loops References: <200007011403.KAA05278@bounty.cisco.com> <395E5F40.E893438C@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > Shail Bhatnagar wrote: > > > > The loop detection algorithm has been changed for proxies so that Request-URI > > is also included in it. This allows spiralling of requests. What is > > the policy for a client that is redirected. For example : > > > > INVITE sip:u@p > > ----------------> > > > > 302 Moved Temporarily > > <---------------- > > Contact: sip:x@p > > > > Should the client retry the INVITE with the changed request-URI. Note that > > this INVITE will be directed to same address and port. > > Yes (if it wants to, of course). > > > As per the bis version : > > > > "To avoid forwarding loops, a user agent client or proxy MUST check whether > > the address returned by a redirect server equals an address tried earlier. > > Sounds good so far. > > > (Addresses match if their host and port number match.)" > Well, this quote is taken from the previous paragraph, which talks about > Via headers: > > "Any redirection (3xx) response MUST NOT suggest any of the addresses in > the Via path of the request in the Contact header field. (Addresses > match if their host and port number match.)" > > I believe this is an artifact from RFC 2543, which never mentions spiral > loops. Correct. THis paragraph needs to be removed. It is OK to suggest addresses in the via path of the request. However, a 3xx response MUST NOT suggest the same URL in the request URI of the request being redirected. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 00:21:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05144 for ; Wed, 5 Jul 2000 00:21:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 77EAE44390; Wed, 5 Jul 2000 00:20:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7AB3F44386 for ; Wed, 5 Jul 2000 00:20:21 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02315; Wed, 5 Jul 2000 00:21:38 -0400 (EDT) Message-ID: <3962B73E.BF5F7646@dynamicsoft.com> Date: Wed, 05 Jul 2000 00:19:10 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Pathangi N Janardhanan , sip@lists.bell-labs.com Subject: Re: [SIP] few questions References: <200006291657.LAA10490@b04a45.exu.ericsson.se> <395D6FE1.D0D7EFC8@dynamicsoft.com> <005c01bfe329$d97d6020$38c9a8c0@labs> <395E62A4.4EA8D296@dynamicsoft.com> <3962B57D.16E4FCAC@dynamicsoft.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Igor Slepchin wrote: > > > > Why would it want to know? Script execution is transparent to user > > agents. > > If a user wants to upload a CPL to a server in a REGISTER, it can simply > try and if it fails with a 415 Unsupported Media, listing the type for > CPL, you know its not supported. Well, I'd rather call it a provisioning client then, not a SIP client. I'd assume that a provisioning client knows the capabilities of the proxy it's trying to provision. After all, if it tries to provision a random proxy, the authentication with that proxy will most likely fail. Finding a proxy with a given set of capabilities is a totally different story. Note that SLP doesn't really work beyond LAN. 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 Jul 5 00:43:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05282 for ; Wed, 5 Jul 2000 00:43:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 52A4344372; Wed, 5 Jul 2000 00:42:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EC78D44346 for ; Wed, 5 Jul 2000 00:42:45 -0400 (EDT) Received: from dynamicsoft.com (1Cust211.tnt4.freehold.nj.da.uu.net [63.36.112.211]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02332; Wed, 5 Jul 2000 00:39:23 -0400 (EDT) Message-ID: <3962BC3A.3BE064D9@dynamicsoft.com> Date: Wed, 05 Jul 2000 00:40:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Shail Bhatnagar , Neil Deason , Sean Olson , vkg@lucent.com, sip@lists.bell-labs.com Subject: Re: [SIP] Max-Forwards + Proxies References: <200006222312.SAA19957@b04a45.exu.ericsson.se> <3952F3E5.982D5382@dynamicsoft.com> <39532457.C5EF0266@ubiquity.net> <395379EA.1D187EED@cisco.com> <3953847A.27A61A4B@dynamicsoft.com> <39538776.E603ABAF@cisco.com> <3953BC06.59B9275E@dynamicsoft.com> <395E3559.52D820ED@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Jonathan Rosenberg wrote: > > > > Shail Bhatnagar wrote: > > > > > > I don't have a problem with this simplification - but the spec says > > > an incoming request with Max-Forwards of 0 MUST NOT be forwarded. > > > It does not say that the request cannot be locally processed and a > > > response returned. Since REGISTER (for the registrar) and CANCEL > > > will be absorbed by the proxy, I thought it is okay to process these > > > requests. > > > The relevant statement in the spec should be appropriately changed - > > > > > > request MUST NOT be forward and MUST NOT be processed. > > > > That is the proposal; as I said, I think it is very confusing otherwise. > > > > -Jonathan R. > > > > Just for reference: Here's the HTTP/1.1 behavior: > > Each proxy or gateway recipient of a TRACE or OPTIONS request > containing a Max-Forwards header field MUST check and update its > value prior to forwarding the request. If the received value is zero > (0), the recipient MUST NOT forward the request; instead, it MUST > respond as the final recipient. If the received Max-Forwards value is > greater than zero, then the forwarded message MUST contain an updated > Max-Forwards field with a value decremented by one (1). I don't have a major problem with this kind of behavior for OPTIONS (I can still reject it with 483 and nothing very bad happens), but for REGISTER this behavior is really bad. So, the current proposal is that proxies don't forward requests with 0 Max-Forwards. If the request is OPTIONS, the entity responds as the final recipient (noting that 483 is a valid response as the final recipient). For all other methods, the final response MUST be 483 if Max-Forwards is zero. Does that seem OK? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 02:24:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17864 for ; Wed, 5 Jul 2000 02:24:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5877844369; Wed, 5 Jul 2000 02:24:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id B182144346 for ; Wed, 5 Jul 2000 02:24:06 -0400 (EDT) Received: from esvir06nok.ntc.nokia.com (esvir06nok.ntc.nokia.com [131.228.10.155]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id JAA07976 for ; Wed, 5 Jul 2000 09:24:04 +0300 (EETDST) From: antti.vaha-sipila@nokia.com Received: from esebh03nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 5 Jul 2000 09:24:04 +0300 Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Wed, 5 Jul 2000 09:24:04 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA502F53E82@treis03nok> To: schulzrinne@cs.columbia.edu, gethin@ubiquity.net Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Wed, 5 Jul 2000 09:24:01 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA17864 Hello, Problems seem to crop up in which was included as to be "compatible" with the RFC 2543. I agree that it should be removed in future versions of RFC 2806. As <"> and "%" are not allowed characters in itself, the issue was mentioned in RFC 2806 section 1.2, meaning that all those special characters must be escaped with the %hex notation before putting them in the URL, resulting in the double escaping you discussed. This is hairy and IMHO it is a very good idea to get rid of the altogether. Sadly, your email about your plans to dump from SIP URLs came a bit too late to be taken into account when writing the first version of RFC 2806. So, my recommendation for tel: URLs is the same: do not use it, it will become deprecated. > Modified spec roughly accordingly. Note that RFC 2806 has a mistake in > that % can never appear as itself. Same for %22 (") and %23 > (#), %3c (<) > and %3e (>), according to RFC 2396. Are you referring to here? Yes, this is mentioned in RFC 2806 section 1.2. All of those chars must be escaped before using them in a tel: URL. This is also said in the BNF comments. The original reason why I listed the characters exclipitly in was that there were some characters that should not be present as the first character of the prefix, to make it distinguishable from and after unescaping. (I do not subscribe to SIP mailing list at the moment, so please Cc: me on replies - thanks.) Antti -- Antti Vähä-Sipilä / Nokia Mobile Phones My views and opinions are not necessarily those of my employer. Send personal email to avs@iki.fi only. http://www.iki.fi/avs/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 02:49:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17972 for ; Wed, 5 Jul 2000 02:49:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0742F4437B; Wed, 5 Jul 2000 02:49:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 2425544352 for ; Wed, 5 Jul 2000 02:49:08 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FX700701PLVUT@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 5 Jul 2000 06:49:07 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FX70062HPLVS9@firewall.mcit.com>; Wed, 05 Jul 2000 06:49:07 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0FX700901PEVNC@pmismtp04.wcomnet.com>; Wed, 05 Jul 2000 06:44:55 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FX700901PEQN3@pmismtp04.wcomnet.com>; Wed, 05 Jul 2000 06:44:55 +0000 (GMT) Received: from C25776A ([166.44.137.62]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FX70031SOXYAS@pmismtp04.wcomnet.com>; Wed, 05 Jul 2000 06:44:43 +0000 (GMT) Date: Wed, 05 Jul 2000 01:48:20 -0500 From: Henry Sinnreich Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) In-reply-to: <3960BA42.B6E2B68E@ubiquity.net> To: Neil Deason , "Gardell, Steve" Cc: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Neil writes: > to build new >services and empower service creation by end users. Yes, another angle is to empower service providers to use 3rd party applications from the ASP world, reselling and outsourcing. This is only possible in the open Internet environment. A proprietary call agent will lock the service provider to one single vendor. But maybe that's what is intended in the first place :-) Henry >-----Original Message----- >From: Neil Deason [mailto:ndeason@ubiquity.net] >Sent: Monday, July 03, 2000 11:08 AM >To: Gardell, Steve >Cc: 'Henry Sinnreich'; 'sip@lists.bell-labs.com' >Subject: Softswitches (was Re: [SIP] SIP->XML->SOAP) > > >Check out: > >http://www.computertelephony.com/article/CTM20000608S0021 > >As Henry explains in more detail here where a 'Softswitch' >is used to preserve the signaling and control architecture >of SS7 and the Intelligent Network the vendor who implements >the Softswitch owns control over services. This reinvents >the failings of the IN/PSTN whereas SIP seeks to build new >services and empower service creation by end users. > >Cheers, >Neil >-- >Ubiquity Software Corporation, UK >http://www.ubiquity.net > >"Gardell, Steve" wrote: >> >> I apologize for the double posting. Read >> "MGC" rather than "MG". What I get for >> going on vacation... >> >> > -----Original Message----- >> > From: Gardell, Steve >> > Sent: Monday, July 03, 2000 7:07 AM >> > To: 'Matt Holdrege'; Henry Sinnreich >> > Cc: sip@lists.bell-labs.com >> > Subject: RE: [SIP] SIP->XML->SOAP >> > >> > >> > I have been on vacation, so appologies for the >> > belated response. After struggling to explain >> > "softswitches" to operations folks here, we >> > settled on a very general definition that could >> > be taken to include MG's, SIP Proxy Servers, >> > H.323 routed GK's as well as the more switch-like >> > constructs being defined by the Multi-Media >> > Switching Forum. However, as near as we can tell, >> > today "softswitch" is a marketing term most >> > closely associated with the IETF MG. >> > >> > What definition is implicit in the "value" commentary >> > here? >> > >> > Steven Gardell >> > GTE Laboratories >> > Voice: 781-466-2681, Fax: 781-466-3375 >> > >> > >> > > -----Original Message----- >> > > From: Matt Holdrege [mailto:matt@ipverse.com] >> > > Sent: Wednesday, June 21, 2000 4:32 PM >> > > To: Henry Sinnreich >> > > Cc: sip@lists.bell-labs.com >> > > Subject: RE: [SIP] SIP->XML->SOAP >> > > >> > > >> > > At 07:09 AM 6/18/00 -0500, Henry Sinnreich wrote: >> > > > >> SIP->XML would converge the SIP methods and required >> > > > >parameters to XML and >> > > > >> allows the introduction of a DTD or schema to define >> > > > >the syntax of a valid >> > > > >> SIP message. >> > > > >> > > >Do not forget that endangering the deployment >of SIP as is, >> > > >would set IP telephony back for a generation >and leave the field >> > > >for "softswitches" and other such nonsense. >Nobody on this >> > > >mailing list would then live to see true/open Internet >> > > >communications, but just the old circuit switch >central control >> > > >model with its terrible signaling. Just using >IP as a cheap >> > > >wire. >> > > >> > > Henry, >> > > >> > > This is the first time I recall seeing >"softswitches" being >> > > denigrated on >> > > an IETF list. I would hope you realize that they are an >> > > enabler to get the >> > > circuit switched world to migrate to open communications? >> > Saying that >> > > Softswitches will preserve the circuit switched >world with >> > > it's "terrible >> > > signalling" is a bit short-sighted. >> > > >> > > You should also realize that SIP is doing quite >well in the >> > > area of market >> > > acceptance. The more people buy into SIP the >more evolution will be >> > > required. Change is inevitable even though we must try to >> > > manage it well. >> > > XML is one such change that seems (to me) to be >inevitable. >> > > So it would be >> > > better to try and manage the interactions with >SIP and XML >> > > here in the IETF >> > > rather than elsewhere. Besides, it's part of the >openess that >> > > we all should >> > > encourage. >> > > >> > > >> > > >> > > _______________________________________________ >> > > SIP mailing list >> > > SIP@lists.bell-labs.com >> > > http://lists.bell-labs.com/mailman/listinfo/sip >> > > >> > >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > >-- >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 Jul 5 04: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 ESMTP id EAA18792 for ; Wed, 5 Jul 2000 04:47:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B76A44368; Wed, 5 Jul 2000 04:47:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from md3.vsnl.net.in (md3.vsnl.net.in [202.54.6.35]) by lists.bell-labs.com (Postfix) with ESMTP id D27A844346 for ; Wed, 5 Jul 2000 04:46:54 -0400 (EDT) Received: from jana ([203.197.130.97]) by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id OAA18984 for ; Wed, 5 Jul 2000 14:13:12 +0530 (IST) Message-ID: <002401bfe65d$b6cb7f80$38c9a8c0@labs> From: "Pathangi N Janardhanan" To: Date: Wed, 5 Jul 2000 14:17:53 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] SIP Usages Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Is there any document or paper which talks about the various applications that can be build for the SIP protocol. Some of the ones are a) use of SIP for VoIP terminal b) Use of SIP for MGC to MGC communication The draft "draft-ietf-sip-isup-mime" talks of carrying ISUP/QSIG messages in SIP messages, where would such a need be felt. For tunneling ISUP/QSIG messages would SIGTRAN not be a better approach? Thanks Jana _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 05:08:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18911 for ; Wed, 5 Jul 2000 05:08:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D770444352; Wed, 5 Jul 2000 05:08:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 8396444336 for ; Wed, 5 Jul 2000 05:08:05 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA02652; Wed, 5 Jul 2000 10:04:30 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Fairlie-Cuninghame, Robert" , Henning Schulzrinne Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Wed, 5 Jul 2000 09:25:14 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00070509583809.27308@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Wed, 05 Jul 2000, Fairlie-Cuninghame, Robert wrote: > The point I was really trying to make is that allowing semicolons and > question marks in the user part will cause problems with existing server > parsers that treat the semicolon as a delimiter to the user@host:port part > or don't support the user=phone parameter. > > For instance, if the parser doesn't support user=phone: > > sip:ABCD;dog=cat@fish.com;user=phone > > will be treated as hostname ABCD with a paramter dog=cat@fish.com (rather > than some uninterpreted user name at fish.com). @ is not allowed in parameters. Therefore it would be possible to delimit the userinfo first by looking for @ and then parsing the host afterwards so in the case above (assuming the ; and ? hasve been added to the user bnf), this can only be resolved as user = ABCD;dog=cat host = fish.com > If the parser determines the end of the user@host:port by searching for a > semicolon then the same thing will occur. This is a valid (as far as I can > see) and simple way for parser to pull out the base URL (until now). do you mean searching for a question mark here? If you do then i agree this is a problem. Slightly modifying your example (whether there is a user parameter or not does not matter): sip:ABCD?dog=cat@fish.com is this host= "ABCD" header = "dog=cat@fish.com" or user = "ABCD?dog=cat" host = "fish.com" > Slightly kludgier but at least syntactically workable would be to > differently quote the meta characters in the tel:. or remove @ from the list of characters in headers and make it have to be escaped. > I would rather a kludge that works nicely than changing the characters > allowable in the user part which further complicates the parsing of a sip > URL. Your suggestion would mean you can only parse a URI correctly by > _first_ locating and understanding one of the parameters !!! Right? But it is not backwards compatible at all If an old parser sees %%3b then it will not correctly parse it anyway. I don't really like adding and removing characters from the BNF but I think it is preferable to adding a new escaping mechanism that will make things fuzzier and more complicated. -- 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 Jul 5 05:27:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18995 for ; Wed, 5 Jul 2000 05:27:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12F2344351; Wed, 5 Jul 2000 05:27:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 2F0B044336 for ; Wed, 5 Jul 2000 05:27:02 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id OAA04694 for ; Wed, 5 Jul 2000 14:56:04 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Wed, 05 Jul 2000 14:56:02 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id OAA09728 for ; Wed, 5 Jul 2000 14:55:57 +0530 (IST) Message-ID: <06a101bfe663$21d7ba00$8c40000a@sasi.com> From: "rafi" To: Date: Wed, 5 Jul 2000 14:56:42 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_069E_01BFE691.3B55FA40" 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] Few doubts Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_069E_01BFE691.3B55FA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 (i) What should be the action of a SIP entity when it receives = a message in which one or more mandatory parameters are missing ? =20 (ii) When UAS ( section 4.2.1) receives another INVITE message = before it has sent the final response to the first INVITE then it = returns a 400 response and includes a Retry-After field with randomly chosen = value. My question is if a random value is to be filled in Retry- = After field then why this header field is a MUST ? Why can't UAC itself = choose random value and resend the INVITE message ? (iii) Many Regular expressions does not prohibit the case of = repetition (it is a=20 limitation rather). For eg, Authorization: pgp signature =3D "xxxx.." signature =3D = "yyyyy...." is valid according to the grammar. In fact there are many = places where these=20 things can happen. What should be the action of SIP entity = in such cases ? Thank You =20 Rafi Assadi H.M. Silicon Automation Systems Bangalore, INDIA =20 ------=_NextPart_000_069E_01BFE691.3B55FA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 Hi,
 
        =20
 
 (i)     What = should be=20 the action  of  a SIP entity  when=20 it receives  a = message
       =  =20 in  which  one or more  mandatory parameters are missing = ?
        
 
 (ii)     = When  UAS (=20 section 4.2.1) receives another INVITE message before
         it=20 has sent the final response to the first INVITE then it returns a=20 400
        =20 response and includes a Retry-After field with randomly chosen=20 value.
         My=20 question is if a random value is to be filled in Retry- After field=20 then
         why this=20  header field is a MUST ? = Why  can't=20 UAC itself  choose
       =   random=20 value  and resend  the  INVITE message ?
 
 (iii)    = Many  Regular=20 expressions does not prohibit the case of  repetition (it is a=20
        =20 limitation rather).  For = eg,
 
          &nbs= p;  =20 Authorization: pgp signature =3D "xxxx.." signature =3D = "yyyyy...."
 
      = is  valid=20 according to the grammar.  In fact there are many places where = these=20
       =20 things can happen. What  should = be =20 the  action  of SIP entity  in such cases = ?
 
Thank You 
Rafi Assadi H.M.
Silicon Automation Systems
Bangalore, INDIA
 
         =20
------=_NextPart_000_069E_01BFE691.3B55FA40-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 05:55:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19139 for ; Wed, 5 Jul 2000 05:55:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6259044382; Wed, 5 Jul 2000 05:55:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from roma.axis.se (roma.axis.se [193.13.178.2]) by lists.bell-labs.com (Postfix) with ESMTP id 3918644336 for ; Wed, 5 Jul 2000 05:55:02 -0400 (EDT) Received: from klatt.axis.se (klatt.axis.se [193.13.178.133]) by roma.axis.se (8.9.3/8.9.3) with ESMTP id LAA21366; Wed, 5 Jul 2000 11:53:28 +0200 (MEST) Received: by klatt.axis.se with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jul 2000 11:53:26 +0200 Message-ID: <151F3D2AE9F0D3119E480004ACB8EA3715BF3A@cluster01.axis.se> From: Peter Kjellerstedt To: "'Gethin Liddell'" , "Fairlie-Cuninghame, Robert" , Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Wed, 5 Jul 2000 11:52:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Gethin Liddell [mailto:gethin@ubiquity.net] > Sent: 05 July 2000 10:25 > To: Fairlie-Cuninghame, Robert; Henning Schulzrinne > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] SIP URL telephone-subscriber syntax. > > On Wed, 05 Jul 2000, Fairlie-Cuninghame, Robert wrote: > > The point I was really trying to make is that allowing semicolons > > and question marks in the user part will cause problems with > > existing server parsers that treat the semicolon as a delimiter > > to the user@host:port part or don't support the user=phone parameter. > > > > For instance, if the parser doesn't support user=phone: > > > > sip:ABCD;dog=cat@fish.com;user=phone > > > > will be treated as hostname ABCD with a parameter dog=cat@fish.com > > (rather than some uninterpreted user name at fish.com). > > @ is not allowed in parameters. Therefore it would be possible to > delimit the userinfo first by looking for @ and then parsing the host > afterwards so in the case above (assuming the ; and ? have been added > to the user bnf), this can only be resolved as > > user = ABCD;dog=cat > host = fish.com Only that this (if I am not mistaken) would make it impossible to make an lalr(1) parser for SIP, which (albeit not as easily as I had hoped for) is possible with the current grammar... //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 Jul 5 06:36:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19448 for ; Wed, 5 Jul 2000 06:36:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0095644385; Wed, 5 Jul 2000 06:36:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.azisa.co.za (mail.azisa.co.za [196.14.124.43]) by lists.bell-labs.com (Postfix) with ESMTP id 7A75E44336 for ; Wed, 5 Jul 2000 06:36:22 -0400 (EDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jul 2000 12:37:28 +0200 Message-ID: <934C10A9A64AD4119440009027E0998801C45E@MAIL> From: Jacobus Alberts To: "Sip List (E-mail)" Subject: [SIP] SIPURL IPv6 address possibly incorrect Date: Wed, 5 Jul 2000 12:37:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hello My apologies if what I am about to raise has already been covered somewhere else in this list, but I have briefly checked, I do not think so. I believe that the ABNF for the IPv6Address is incorrect. In RFC2373, an extra element is defined as IPv6prefix = hexpart "/" 1*2DIGIT and then subsequently, IPv6address = IPv6prefix [":" IPv4address] The above definition is more sensible to me, since ":" can occur in the hexpart. If the definition from the RFC2543 is used, hexpart replaces IPv6prefix above. Then it would be impossible to distinguish between a ":" in the hexpart or the ":" delimiting the optional IPv4address (should you want to parse such that IPv4address could be extracted of course!) Have I missed some comment in the RFC regarding this? Or is the issue raised valid? Jacobus Alberts Azisa (Pty) Ltd email: jalberts@azisa.co.za _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 07:26:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20100 for ; Wed, 5 Jul 2000 07:26:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9682D44388; Wed, 5 Jul 2000 07:25:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.gte.com (unknown [132.197.8.26]) by lists.bell-labs.com (Postfix) with ESMTP id 7D21744336 for ; Wed, 5 Jul 2000 07:25:38 -0400 (EDT) Received: from sigmail.gte.com (sigmail.gte.com [132.197.120.75]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id HAA20636; Wed, 5 Jul 2000 07:25:35 -0400 (EDT) Received: by sigmail.gte.com with Internet Mail Service (5.5.2232.9) id <3GRG5GFS>; Wed, 5 Jul 2000 07:24:15 -0400 Message-ID: From: "Gardell, Steve" To: "'Matt Holdrege'" , Henry Sinnreich Cc: sip@lists.bell-labs.com Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) Date: Wed, 5 Jul 2000 07:24:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Matt Holdrege [mailto:matt@ipverse.com] > Sent: Tuesday, July 04, 2000 11:35 AM > To: Henry Sinnreich > Cc: sip@lists.bell-labs.com > Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) > > > At 11:12 AM 7/4/00 -0500, Henry Sinnreich wrote: > >Matt, thanks for the reasoned note. One item: > > >A SIP phone may not need a > > >softswitch to do this, > > >but the umpteen billion non-SIP phones need a little help. > > > >SIP RJ-11 to RJ-45 adapters are now available and could be > >available as consumer devices with consumer price points. Such > >adapters are actually one-channel IP telephony gateways and are > >fully qualified SIP UAs under user control. Compliant with > >Internet transparency. Personally, I would always prefer a SIP > >Ethernet to black phone adapter that gives me free choice of > >service provider to xGCP phones controlled by the Telco as in > >old times. Would you really have your analog phones controlled > >by the Telco, rather then being able to point them to any SIP > >server of your choice? > > Sure, but I think it may be a few years before everyone in > the world has > such a phone which is why we need to help them into a more open > architecture. Even with XGCP controlled phones, things are > way more open > than with the circuit-switched world. > Exactly to my point. There are undoubtedly exciting "green field" opportunities for SIP services; however the many millions of "copper loops" in place are not going away anytime soon. Architectures are required that support a **migration** towards the pure packet world aptly addressed by SIP. We should also bear in mind the lessons of IN - An industry standard protocol (in that case TCAP) is a necessary, but **insufficient** condition for open competitive service creation. The comparison is not perfect, but neither is it irrelevant. Enough, I guess, of the "evil telco" perspective... > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 5 07:43:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20404 for ; Wed, 5 Jul 2000 07:43:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6B31A44396; Wed, 5 Jul 2000 07:43:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.gte.com (unknown [132.197.8.26]) by lists.bell-labs.com (Postfix) with ESMTP id 4CAAB44336 for ; Wed, 5 Jul 2000 07:43:12 -0400 (EDT) Received: from sigmail.gte.com (sigmail.gte.com [132.197.120.75]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id HAA21370; Wed, 5 Jul 2000 07:43:08 -0400 (EDT) Received: by sigmail.gte.com with Internet Mail Service (5.5.2232.9) id <3GRG5GFW>; Wed, 5 Jul 2000 07:41:48 -0400 Message-ID: From: "Gardell, Steve" To: "'Jonathan Rosenberg'" , Serban Tatu Cc: siplist Subject: RE: [SIP] authentication at gateway Date: Wed, 5 Jul 2000 07:41:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 05, 2000 12:01 AM > To: Serban Tatu > Cc: siplist > Subject: Re: [SIP] authentication at gateway > > > THe most likely scenario is one you left out: the prompting and > collection for the PIN are all performed by the originating > gateway. In > general, the entity demanding authentication will not know that the > request is through a gateway. I believe its unlikely the entity would > return 200 OK, or even a 401 with content. Rather, just a 401. > > So, upon receiving the 401, the gateway performs some local > operation to > get the username and password. Perhaps it plays out an > announcement and > collects the username/password; perhaps they are simply established > ahead of time and stored in a database - the gateway just fetches them > when prompted for authentication. > A practical issue with this approach is that gateways are often deployed in support of many different services that may have different authentication requirements. Placing all of the authentication smarts in the gateway makes it difficult to roll out new services. Now admittedly this is a "telco centric" view of the service world - I suggest that the appropriate "converged" architecture is to have authentication controlled from outside the gateway and to implement it via a SIP Proxy(like?) element in situations where we want the core service to be agnostic as to whether the endpoint is a gateway or a UA. > -Jonathan R. > > Serban Tatu wrote: > > > > Hi, > > > > How is authentication performed by a SIP-enabled gateway? > Let's say somebody on > > a PSTN phone wants to gain access to a service and > therefore has to provide a > > username/password. Some scenarios come to mind (newbie > > here): > > > > Scenario 1 (smart gateway): > > > > - SIP UAS at service side sends a 401 unauthorized as a > response to the INVITE. > > The response contains a voice prompt audio file (e.g. > Gimme > > username/password). > > - gateway is so smart that it knows how to play the prompt > and collect DTMF > > tones representing username and password, which it then > sends back encoded > > somehow to the service. > > > > Scenario 2 (not so smart gateway): > > > > - SIP UAS at service side sends back a 200 OK response to > the INVITE. The > > response contains the voice prompt as before. > > - gateway knows how to play the audio file, sends ACK, > media connections are > > open. > > - SIP UAS at service side then sends an INFO message with a > DTMF collection > > scheme (voice prompt could also be sent here). > > - gateway collects the tones and sends them back with > another INFO message. > > > > Scenario 3 (dumb gateway): > > > > - SIP UAS at service side sends back a 200 OK response to > the INVITE. > > - gateway and SIP UAS establish their media channels. > > - service then plays the whole authentication scenario > through the media > > channels. Gateway lets DTMF tones flow through the media path. > > > > Do any of these scenarios make any sense? It seems to me > that 1 and 2 are sci-fi > > given the current gateway solutions, while 3 might not be > possible because the > > gateway grabs the DTMF tones, or if it doesn't then it's an > ugly solution since > > signaling and media are all mixed together. > > > > Thanks, > > Serban > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 08:28:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24775 for ; Wed, 5 Jul 2000 08:28:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CF0564438A; Wed, 5 Jul 2000 08:28:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 2667144336 for ; Wed, 5 Jul 2000 08:28:14 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id RAA11436 for ; Wed, 5 Jul 2000 17:57:13 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Wed, 05 Jul 2000 17:57:11 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id RAA12797 for ; Wed, 5 Jul 2000 17:57:12 +0530 (IST) Message-ID: <074501bfe67c$7264b900$8c40000a@sasi.com> From: "rafi" To: Date: Wed, 5 Jul 2000 17:57:55 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0742_01BFE6AA.8BF23B80" 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] on directed pick up service Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0742_01BFE6AA.8BF23B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to understand how "directed pick up" service can be achieved using SIP. RFC 2543 mentions following=20 paragraph regarding this " If a registration is changed while a user agent or proxy server processes an invitation, new information SHOULD be used " Now consider the following scenario =20 A -------------------B ----------------C (user 1) (user 2) (user 2 currently present here ) User 1 at A is calling user 2 at B who is currently present at C. Initially an INVITE message is send to B which process the message. User 2 who is currently at C comes to know about the call at C(How exactly C comes to know that a call for him is pending at B is not = known to me). User 2 now changes his registration so that he can receive = call at C. But how A come to know about that without releasing current call it = not clear to me. Can someone help me in understanding this ? I know I am = missing some point here. Thank You Rafi Assadi H.M. Silicon Automation Systems Bangalore, INDIA ------=_NextPart_000_0742_01BFE6AA.8BF23B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
        I am=20 trying to understand how "directed pick up" service
can be achieved using SIP. RFC 2543 = mentions=20 following
paragraph regarding this
 
   " If a registration is = changed while a=20 user agent or proxy server
processes an invitation, new = information SHOULD be=20 used "
 
   Now consider the following = scenario
 
 
  A -------------------B =20 ----------------C
 (user=20 1)          (user=20 2)          (user 2 = currently =20 present here )
 
 
 User 1 at A is calling  = user 2  at=20 B who is  currently present at C.
 Initially an=20  INVITE message is send to B = which process=20 the message.
 User 2 who is=20 currently at C  comes to know about the call at C(How
exactly  C comes to = know  that a = call for him is=20 pending at B is not known
 to me).  User 2 now changes=20 his registration so that he can = receive call at=20 C.
 But how  A come = to know about that without releasing current = call it not=20 clear
 to me. Can someone help me in = understanding=20 this ?  I know  I am missing
some point here.
 
 
Thank You
Rafi Assadi H.M.
Silicon Automation Systems
Bangalore, INDIA
 
 
------=_NextPart_000_0742_01BFE6AA.8BF23B80-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 08:29:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24942 for ; Wed, 5 Jul 2000 08:29:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B365144399; Wed, 5 Jul 2000 08:29:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id AE72D44397 for ; Wed, 5 Jul 2000 08:29:05 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e65CMHs14266; Wed, 5 Jul 2000 14:22:17 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA19335; Wed, 5 Jul 2000 15:22:16 +0300 (EET DST) Message-ID: <39632848.ADB887B8@lmf.ericsson.se> Date: Wed, 05 Jul 2000 15:21:28 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip , schulzrinne@cs.columbia.edu, jdrosen@dynamicsoft.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP References: <3961992B.793643F7@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Some folks have pointed out that this is a similar problem to the one DCS was trying to solve using the double-stage INVITE. This is actually true, but I do not like the double-stage INVITE approach. In the following example C will be the 3rd party, and the media session will be established between A and B: C sends an INVITE to A without SDP (issue: how can C state that QoS will be needed if there is not SDP in the INVITE?) A responds with 183 with a SDP. C sends an INVITE to B with the SDP received from A. We can specify QoS preconditions here. B responds with 183 with its SDP and begin performing resource reservation in the path B->A How can now C send B's SDP to A?? If A does not have B's SDP it cannot perform resource reservation in the path A->B... Can we re-INVITE A at this stage? Thanks, Gonzalo Gonzalo Camarillo wrote: > > Hi, > > The draft "Third Party Call Control in SIP", which can be found at > http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt > > outlines a method for establishing a session between two hosts that have > signalling (SIP) relationships with a 3rd host that is not involved in > the session. > > The idea is basically to send an INVITE to A-party without SDP and then > send the SDP coming from the B-party in the ACK. > > This works fine when no QoS is needed. If preconditions must be used > this method fails. Preconditions cannot be added to the SDP in the ACK, > since ACKs trigger no responses. > > Both parties involved in the session have to know both SDP descriptions > in order to perform resource reservation (with RSVP, for instance). > Then, COMET will have to be sent. > > Have somebody taken this into account regarding this draft? Any ideas? > > 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 > > _______________________________________________ > 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 08: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 ESMTP id IAA28660 for ; Wed, 5 Jul 2000 08:54:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B274D4438D; Wed, 5 Jul 2000 08:53:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 1681544336 for ; Wed, 5 Jul 2000 08:53:49 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA17324; Wed, 5 Jul 2000 13:51:41 +0100 (BST) From: "Jo Hornsby" To: "rafi" , Subject: RE: [SIP] on directed pick up service Date: Wed, 5 Jul 2000 13:51:40 +0100 Message-ID: <001601bfe67f$c378eb60$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: <074501bfe67c$7264b900$8c40000a@sasi.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I am trying to understand how "directed pick up" service > can be achieved using SIP. RFC 2543 mentions following > paragraph regarding this > > " If a registration is changed while a user agent or proxy server > processes an invitation, new information SHOULD be used " > > Now consider the following scenario > > > A -------------------B ----------------C > (user 1) (user 2) (user 2 currently present here ) > > > User 1 at A is calling user 2 at B who is currently present at C. > Initially an INVITE message is send to B which process the message. > User 2 who is currently at C comes to know about the call at C(How > exactly C comes to know that a call for him is pending at B is not > known to me). One example is that User 2 hears B ringing. > User 2 now changes his registration so that he can > receive call at C. But how A come to know about that without > releasing current call it not clear to me. Can someone help me in > understanding this ? I know I am missing some point here. Yes, you are missing a point -- the call has to be made through a proxy. &:) (Actually, that's probably not entirely true. If the registration was made over multicast, for instance, A could have listened. And no doubt there's lots of other ways similar results could be achieved.) Basically, a typical call flow for such a scenario would be: A --INVITE--> P B --INVITE--> C --INVITE--> <---180---- <--RINGING- (At this point, User 2 hears B ringing from C) <--------REGISTER-------- -----------200----------> ----------INVITE--------> <--------RINGING--------- <----------200----------- --CANCEL--> (yada yada) (In the above case, P is a forking proxy that CANCELs pending branches upon reception of a 200 response, and which also acts as a Registrar.) HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 10:25:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05290 for ; Wed, 5 Jul 2000 10:25:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B3524439F; Wed, 5 Jul 2000 10:23:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by lists.bell-labs.com (Postfix) with ESMTP id 33E1F44341 for ; Wed, 5 Jul 2000 10:22:58 -0400 (EDT) Received: from pqm-cons.demon.co.uk ([158.152.93.237] helo=P162U) by finch-post-10.mail.demon.net with smtp (Exim 2.12 #1) id 139q4m-000Ix0-0A; Wed, 5 Jul 2000 14:22:56 +0000 From: "Alex Hardisty" To: "Jo Hornsby" , "rafi" , Subject: RE: [SIP] on directed pick up service Date: Wed, 5 Jul 2000 15:25:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <001601bfe67f$c378eb60$4e34c3c1@ubiquity.co.uk> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo, > Yes, you are missing a point -- the call has to be made through a > proxy. &:) Is it as simple as you make it sound? 1) How do I know which proxy to send my pick-up request (the REGISTER in your example) to? Surely, I'd want to send it to the UA that I can hear ringing? 2) Directed call pick-up requires me to enter the number of the telephone that is ringing, so am I entering the number of the UA or am I entering my personal number? If the latter it's not Directed Call Pickup but Personal User Mobility. What's the service definition here? > (Actually, that's probably not entirely true. If the registration > was made over multicast, for instance, A could have listened. And > no doubt there's lots of other ways similar results could be > achieved.) > > Basically, a typical call flow for such a scenario would be: > > A --INVITE--> P B --INVITE--> C > --INVITE--> > <---180---- > <--RINGING- > (At this point, User 2 hears B ringing from C) > <--------REGISTER-------- > -----------200----------> > ----------INVITE--------> > <--------RINGING--------- > <----------200----------- > --CANCEL--> > (yada yada) In your example I don't understand why B sends an INVITE to C before it receives the INVITE from the proxy. -- Alex Hardisty PQM Consultants _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 11:02:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08029 for ; Wed, 5 Jul 2000 11:02:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D71B4439D; Wed, 5 Jul 2000 11:01:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id CB8A944341 for ; Wed, 5 Jul 2000 11:01:30 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA25458; Wed, 5 Jul 2000 15:58:21 +0100 (BST) From: "Jo Hornsby" To: "Alex Hardisty" , "rafi" , Subject: RE: [SIP] on directed pick up service Date: Wed, 5 Jul 2000 15:58:21 +0100 Message-ID: <001701bfe691$75e5bce0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Is it as simple as you make it sound? Well, no doubt it can be far more convoluted; I was representing a simple case that required nothing outsida 2543. > 1) How do I know which proxy to send my pick-up request (the REGISTER > in your example) to? Surely, I'd want to send it to the UA that I can > hear ringing? The thing is, it's not a "pick-up request"; it's using existing SIP mechanisms to achieve an affect similar to directed pick-up. Now, of course, it would be possible to define some method, or something, which B could act upon, but that would require extensions. It would also be possible just to use existing SIP mechanisms in the same way, and allow A to act as a registrar (this is similar to the listening to multicast I mentioned). All of these methods have their pros and cons, and no doubt I've missed a plethora of other options. > 2) Directed call pick-up requires me to enter the number of the > telephone that is ringing, so am I entering the number of the UA or > am I entering my personal number? If the latter it's not Directed > Call Pickup but Personal User Mobility. What's the service > definition here? Now you're exposing my ignorance of "convential telephony" (IN?) terminology. Apologies. The REGISTER request sent in this case would probably typically be the SIP URL seen by the proxy in the INVITE request, which would be "Personal User Mobility", I guess. That need not necessarily be the case, however, if the proxy is clever enough to notice that the SIP URL it had resolved to had been given a new registration (this would be "Directed Call Pickup"?). > > (Actually, that's probably not entirely true. If the registration > > was made over multicast, for instance, A could have listened. And > > no doubt there's lots of other ways similar results could be > > achieved.) > > > > Basically, a typical call flow for such a scenario would be: > > > > A --INVITE--> P B --INVITE--> C > > --INVITE--> > > <---180---- > > <--RINGING- > > (At this point, User 2 hears B ringing from C) > > <--------REGISTER-------- > > -----------200----------> > > ----------INVITE--------> > > <--------RINGING--------- > > <----------200----------- > > --CANCEL--> > > (yada yada) > > In your example I don't understand why B sends an INVITE to C before it > receives the INVITE from the proxy. You got me (it shouldn't be there)! &:) Not that I was using it for spacing, or anything... - 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 Jul 5 12:03:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09657 for ; Wed, 5 Jul 2000 12:03:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D307C443A5; Wed, 5 Jul 2000 12:02:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 3812144341 for ; Wed, 5 Jul 2000 12:02:51 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id VAA17568; Wed, 5 Jul 2000 21:31:50 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Wed, 05 Jul 2000 21:31:50 +0000 (IST) Received: from pcg142 (pcg142.sasi.com [10.0.64.142]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id VAA18701; Wed, 5 Jul 2000 21:31:48 +0530 (IST) Message-ID: <007101bfe69a$5c0a6380$8e40000a@sasi.com> From: "Krishna G" To: "Jo Hornsby" Cc: References: <001601bfe67f$c378eb60$4e34c3c1@ubiquity.co.uk> Subject: Re: [SIP] on directed pick up service Date: Wed, 5 Jul 2000 21:32:03 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Jo, I have not understood a few things in UR response. Please find my questions embedded below some specific points of UR response. > > I am trying to understand how "directed pick up" service > > can be achieved using SIP. RFC 2543 mentions following > > paragraph regarding this > > > > " If a registration is changed while a user agent or proxy server > > processes an invitation, new information SHOULD be used " > > > > Now consider the following scenario > > > > > > A -------------------B ----------------C > > (user 1) (user 2) (user 2 currently present here ) > > > > > > User 1 at A is calling user 2 at B who is currently present at C. > > Initially an INVITE message is send to B which process the message. > > User 2 who is currently at C comes to know about the call at C(How > > exactly C comes to know that a call for him is pending at B is not > > known to me). > > One example is that User 2 hears B ringing. *** What R the other ways? What is the purpose of the INVITE from B to C in UR call flow diagram? > > > User 2 now changes his registration so that he can > > receive call at C. But how A come to know about that without > > releasing current call it not clear to me. Can someone help me in > > understanding this ? I know I am missing some point here. > > Yes, you are missing a point -- the call has to be made through a > proxy. &:) > > (Actually, that's probably not entirely true. If the registration > was made over multicast, for instance, A could have listened. And > no doubt there's lots of other ways similar results could be > achieved.) > > Basically, a typical call flow for such a scenario would be: > > A --INVITE--> P B --INVITE--> C > --INVITE--> > <---180---- > <--RINGING- > (At this point, User 2 hears B ringing from C) > <--------REGISTER-------- > -----------200----------> > ----------INVITE--------> > <--------RINGING--------- > <----------200----------- > --CANCEL--> > (yada yada) > > (In the above case, P is a forking proxy that CANCELs pending > branches upon reception of a 200 response, and which also acts as > a Registrar.) > > HTH, > > > - Jo. *** Now how does C know that it has to send the REGISTER request to P? What should the user do if the Registrar entity he has registered with is diferent from the Proxy (P in UR example)? Lets assume that the Proxy P is the Registrar for the user. Now are U saying that the Proxy/Registrar entity (P in UR example) should check if it has sent an INVITE message to the user from whom it has received a REGISTER. If it has, then it should send another INVITE message, this time to C? Could U please clarify the above things. Thanks and Regards, Krishna G. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 12:29:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10660 for ; Wed, 5 Jul 2000 12:29:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9BD57443A7; Wed, 5 Jul 2000 12:28:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id C3D5C44341 for ; Wed, 5 Jul 2000 12:28:31 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA20902; Wed, 5 Jul 2000 17:26:18 +0100 (BST) From: "Jo Hornsby" To: "Krishna G" Cc: Subject: RE: [SIP] on directed pick up service Date: Wed, 5 Jul 2000 17:26:17 +0100 Message-ID: <001a01bfe69d$beff2770$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: <007101bfe69a$5c0a6380$8e40000a@sasi.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > One example is that User 2 hears B ringing. > > *** What R the other ways? I don't know -- could be literally anything (although some, such as another "telephone call", might defeat the purpose...). Being paged (over some sort of PA system) might be another example. > What is the purpose of the INVITE from > B to C in > UR call flow diagram? To once-again reaffirm that I'm a complete muppet. &:) > > Basically, a typical call flow for such a scenario would be: > > > > A --INVITE--> P B --INVITE--> C > > --INVITE--> > > <---180---- > > <--RINGING- > > (At this point, User 2 hears B ringing from C) > > <--------REGISTER-------- > > -----------200----------> > > ----------INVITE--------> > > <--------RINGING--------- > > <----------200----------- > > --CANCEL--> > > (yada yada) > > > > (In the above case, P is a forking proxy that CANCELs pending > > branches upon reception of a 200 response, and which also acts as > > a Registrar.) > > *** Now how does C know that it has to send the REGISTER request to P? Blind faith. &:) But seriously, this is where things potentially break-down, or not. Something like "Directed Pick-Up" (if indeed that is the correct term) does require some sort of sane configuration/application. The best analogy I can think of is of a small office that has their own Telephone Switch. All inbound calls to that office go through this Switch. Now if you replace that Switch with a Proxy, then hopefully things become a little clearer. This scenario does require all the appropriate admistration/configuration of the Proxy being the only entry point onto the SIP "network", and that all UAs in the office use that Proxy as their Registrar. > What should the user do if the Registrar entity he has > registered with is diferent from the Proxy (P in UR example)? Caveat: as long as User 2 is allowed to register from C, that isn't really a problem; a UA can register with multiple registrars. > Lets assume that the Proxy P is the Registrar for the user. Now > are U saying that the Proxy/Registrar entity (P in UR example) > should check if it has sent an INVITE message to the user > from whom it has received a REGISTER. If it has, then it should > send another INVITE message, this time to C? Yes. That's exactly it. One point I neglected to mention before was that this isn't exactly the same as "Directed Pick-Up" (in my experience of the term), anyway. P may send an additional INVITE to C, but that doesn't mean that B stops ringing (indeed, I can imagine situations where that would be completely undesirable -- preemptively registering a holiday address, for example -- since User 2's call would suddenly "disappear"). It's only once User 2 picks up from C, that B _might_ stop ringing. - 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 Jul 5 12:53:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11417 for ; Wed, 5 Jul 2000 12:53:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57F514439A; Wed, 5 Jul 2000 12:53:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mayo.cisco.com (mayo.cisco.com [161.44.3.207]) by lists.bell-labs.com (Postfix) with ESMTP id 4088B44341 for ; Wed, 5 Jul 2000 12:53:11 -0400 (EDT) Received: from cisco.com (mayo.cisco.com [161.44.3.207]) by mayo.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA23014 for ; Wed, 5 Jul 2000 12:52:37 -0400 (EDT) Message-ID: <396367D5.67943412@cisco.com> Date: Wed, 05 Jul 2000 12:52:37 -0400 From: Nilesh Trivedi Organization: Packet Development Unit X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Hide header processing. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello All, Good afternoon. I have some basic doubts about Hide header processing at the proxy. The SIP specs say that a server hides the host and port parts of the top-most Via header if a request contains "Hide:hop" header field. This falls under hop-by-hop encryption since the proxy which encrypted it will be the one to decrypt it on response. But it also says that a server capable of hiding Via headers MUST attempt to decrypt all Via headers to do loop detection, if I have understood it correctly then this conflicts with the basic mechanism of hiding the previous Via. How does the proxy know in which form the Via's have been encrypted if it has to decrypt all of them? since they have not been encrypted by itself. Also, if an upstream agent is requesting Hide it does so assuming the proxy is capable of doing so, so what if the proxy is not capable of?. I would highly appreciate if someone can throw some light on these questions. Thanks for your time in advance. Have a nice day!! Regards, Nilesh Trivedi. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 13:11:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11997 for ; Wed, 5 Jul 2000 13:11:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B033F443AA; Wed, 5 Jul 2000 13:11:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 4C7E04437D for ; Wed, 5 Jul 2000 13:11:03 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id SAA04514; Wed, 5 Jul 2000 18:09:03 +0100 (BST) From: "Jo Hornsby" To: "Nilesh Trivedi" , Subject: RE: [SIP] Hide header processing. Date: Wed, 5 Jul 2000 18:09:02 +0100 Message-ID: <001d01bfe6a3$b76795a0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: <396367D5.67943412@cisco.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I have some basic doubts about Hide header processing at the proxy. Don't we all. &:) > The SIP specs say that a server hides the host and port parts of the > top-most Via header if a request contains "Hide:hop" header field. > > This falls under hop-by-hop encryption since the proxy which > encrypted it will be the one to decrypt it on response. But it also > says that a server capable of hiding Via headers MUST attempt > to decrypt all Via headers to do loop detection, if I have understood > it correctly then this conflicts with the basic mechanism of hiding > the previous Via. How does the proxy know in which form the Via's > have been encrypted if it has to decrypt all of them? since they have > not been encrypted by itself. I think the point is that if it does manage to decrypt a Via, then the request is probably looped, because you wouldn't expect Proxy X to be able to decrypt a Via encrypted by Proxy Y. (The recommentation of adding "salt" is a good one, since it should go some way to preventing instance 2 of Proxy X from decrypting a Via encrypted by instance 1 of Proxy X.) Note that there are a few changes to loop detection as the result of so-called "Legal Loops", and as such, just being able to decrypt a Via does not necessarily imply that the request has looped. (Working with the algorithm suggested in 6.47.5 of the most recent bis (July), is one way to ensure that the request hasn't just spiralled.) > Also, if an upstream agent is requesting Hide it does so assuming the > proxy is capable of doing so, so what if the proxy is not capable of?. The useragent loses. There's no way to mandate it (I note it's only a SHOULD). HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 13:28:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12354 for ; Wed, 5 Jul 2000 13:28:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E19D04439A; Wed, 5 Jul 2000 13:28:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newman.gte.com (unknown [132.197.8.26]) by lists.bell-labs.com (Postfix) with ESMTP id 40CD044341 for ; Wed, 5 Jul 2000 13:28:35 -0400 (EDT) Received: from sigmail.gte.com (sigmail.gte.com [132.197.120.75]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id NAA01189 for ; Wed, 5 Jul 2000 13:28:35 -0400 (EDT) Received: by sigmail.gte.com with Internet Mail Service (5.5.2232.9) id <3GRG5GLA>; Wed, 5 Jul 2000 13:27:14 -0400 Message-ID: From: "Gardell, Steve" To: "'sip@lists.bell-labs.com'" Date: Wed, 5 Jul 2000 13:27:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Java Media Framework integration Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com In the Java world, SIP and the latest version of the Media Framework appear to be natural partners. I would be grateful of any comments, suggestions, experience reports, or of course, sample code along these lines. Steven Gardell GTE Laboratories 781-466-2681, FAX: 781-466-3375 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 13:46:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12774 for ; Wed, 5 Jul 2000 13:46:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C035E443B8; Wed, 5 Jul 2000 13:45:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id C6DE944341 for ; Wed, 5 Jul 2000 13:45:47 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAB29686; Wed, 5 Jul 2000 10:45:59 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAB35191; Wed, 5 Jul 2000 10:42:26 -0700 (PDT) Message-Id: <4.2.0.58.20000705103601.01b4b300@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jul 2000 10:44:59 -0700 To: "rafi" From: Rohan Mahy Subject: Re: [SIP] on directed pick up service Cc: In-Reply-To: <074501bfe67c$7264b900$8c40000a@sasi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Rafi, et al. Presumably, A sent the call to a (forking) proxy acting on behalf of user2. Presumably the proxy has access to changes in registrations, either directly or through some event notification process. when user2's proxy gets a REGISTER for user2 from C, it should extend an INVITE to C based on this new information. it could also CANCEL the INVITE to B, or just allow both to proceed until either B or C sent a final response. user2 knows to send the REGISTER to that proxy preumably because there was a button (for example) on the phone associated with a URL, which happened to be a register for user2. if you wanted to do directed pickup, you would collect the userinfo portion of the register and insert that in the URL, and you would probably make the Expires header time very short. thanks, -rohan At 05:27 AM 7/5/00 , rafi wrote: > >Hi, > > I am trying to understand how "directed pick up" service >can be achieved using SIP. RFC 2543 mentions following >paragraph regarding this > > " If a registration is changed while a user agent or proxy server >processes an invitation, new information SHOULD be used " > > Now consider the following scenario > > > A -------------------B ----------------C > (user 1) (user 2) (user 2 currently present here ) > > > User 1 at A is calling user 2 at B who is currently present at C. > Initially an INVITE message is send to B which process the message. > User 2 who is currently at C comes to know about the call at C(How >exactly C comes to know that a call for him is pending at B is not known > to me). User 2 now changes his registration so that he can receive call > at C. > But how A come to know about that without releasing current call it not > clear > to me. Can someone help me in understanding this ? I know I am missing >some point here. > > >Thank You >Rafi Assadi H.M. >Silicon Automation Systems >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 Jul 5 13:52:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12923 for ; Wed, 5 Jul 2000 13:52:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7315B443BF; Wed, 5 Jul 2000 13:51:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 6B11B443B6 for ; Wed, 5 Jul 2000 13:51:35 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA19444; Wed, 5 Jul 2000 10:51:47 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAB35246; Wed, 5 Jul 2000 10:48:12 -0700 (PDT) Message-Id: <4.2.0.58.20000705104649.01b6fb40@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jul 2000 10:50:35 -0700 To: "Gardell, Steve" From: Rohan Mahy Subject: RE: [SIP] authentication at gateway Cc: "'Jonathan Rosenberg'" , Serban Tatu , siplist In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Obviously you have to write the smarts somewhere. If you want scalability, the more of that stuff you push to the edges, the better your deployment will scale. If it is painful to touch the edges, then you may do more of the work in the center. The nice thing is, whosoever deployeth services using SIP may chooseth the manner suitable to their network. thanks, -rohan At 04:41 AM 7/5/00 , Gardell, Steve wrote: > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Wednesday, July 05, 2000 12:01 AM > > To: Serban Tatu > > Cc: siplist > > Subject: Re: [SIP] authentication at gateway > > > > > > THe most likely scenario is one you left out: the prompting and > > collection for the PIN are all performed by the originating > > gateway. In > > general, the entity demanding authentication will not know that the > > request is through a gateway. I believe its unlikely the entity would > > return 200 OK, or even a 401 with content. Rather, just a 401. > > > > So, upon receiving the 401, the gateway performs some local > > operation to > > get the username and password. Perhaps it plays out an > > announcement and > > collects the username/password; perhaps they are simply established > > ahead of time and stored in a database - the gateway just fetches them > > when prompted for authentication. > > > > >A practical issue with this approach is that gateways are often >deployed in support of many different services that may have >different authentication requirements. Placing all of the >authentication smarts in the gateway makes it difficult to roll >out new services. Now admittedly this is a "telco centric" view >of the service world - I suggest that the appropriate "converged" >architecture is to have authentication controlled from outside >the gateway and to implement it via a SIP Proxy(like?) element in >situations where we want the core service to be agnostic as to whether >the endpoint is a gateway or a UA. > > > > -Jonathan R. > > > > Serban Tatu wrote: > > > > > > Hi, > > > > > > How is authentication performed by a SIP-enabled gateway? > > Let's say somebody on > > > a PSTN phone wants to gain access to a service and > > therefore has to provide a > > > username/password. Some scenarios come to mind (newbie > > > here): > > > > > > Scenario 1 (smart gateway): > > > > > > - SIP UAS at service side sends a 401 unauthorized as a > > response to the INVITE. > > > The response contains a voice prompt audio file (e.g. > > Gimme > > > username/password). > > > - gateway is so smart that it knows how to play the prompt > > and collect DTMF > > > tones representing username and password, which it then > > sends back encoded > > > somehow to the service. > > > > > > Scenario 2 (not so smart gateway): > > > > > > - SIP UAS at service side sends back a 200 OK response to > > the INVITE. The > > > response contains the voice prompt as before. > > > - gateway knows how to play the audio file, sends ACK, > > media connections are > > > open. > > > - SIP UAS at service side then sends an INFO message with a > > DTMF collection > > > scheme (voice prompt could also be sent here). > > > - gateway collects the tones and sends them back with > > another INFO message. > > > > > > Scenario 3 (dumb gateway): > > > > > > - SIP UAS at service side sends back a 200 OK response to > > the INVITE. > > > - gateway and SIP UAS establish their media channels. > > > - service then plays the whole authentication scenario > > through the media > > > channels. Gateway lets DTMF tones flow through the media path. > > > > > > Do any of these scenarios make any sense? It seems to me > > that 1 and 2 are sci-fi > > > given the current gateway solutions, while 3 might not be > > possible because the > > > gateway grabs the DTMF tones, or if it doesn't then it's an > > ugly solution since > > > signaling and media are all mixed together. > > > > > > Thanks, > > > Serban > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 14:04:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13121 for ; Wed, 5 Jul 2000 14:04:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC98D443B9; Wed, 5 Jul 2000 14:03:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 7385B44341 for ; Wed, 5 Jul 2000 14:03:43 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA29423; Wed, 5 Jul 2000 11:03:55 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAB35397; Wed, 5 Jul 2000 11:00:22 -0700 (PDT) Message-Id: <4.2.0.58.20000705102221.01b55100@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jul 2000 11:02:54 -0700 To: "rafi" From: Rohan Mahy Subject: Re: [SIP] Few doubts Cc: In-Reply-To: <06a101bfe663$21d7ba00$8c40000a@sasi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 02:26 AM 7/5/00 , rafi wrote: > > Hi, > > > > (i) What should be the action of a SIP entity when it receives a > message > in which one or more mandatory parameters are missing ? Send an apropos error, ex: 400 Bad Request. > (ii) When UAS ( section 4.2.1) receives another INVITE message before > it has sent the final response to the first INVITE then it > returns a 400 > response and includes a Retry-After field with randomly chosen > value. > My question is if a random value is to be filled in Retry- After > field then > why this header field is a MUST ? Why can't UAC itself choose > random value and resend the INVITE message ? This late in SIP's development, WHY questions are sort of futile. The correct answer at this point is because a) lots of people implemented it that way, and b) it works. I'm sure if you are curious you can dredge through the mailing list archives for the answer. It could be a very good reason, or it could be arbitrary (I don't know), but as long as the mechanism works, who cares! > > (iii) Many Regular expressions does not prohibit the case > of repetition (it is a > limitation rather). For eg, > > Authorization: pgp signature = "xxxx.." signature = "yyyyy...." > > is valid according to the grammar. In fact there are many places > where these > things can happen. What should be the action of SIP entity in > such cases ? Unlike ASN.1 and DTDs, ANBF doesn't deal with repetition. You have to use the semantics and common sense to tell you that only one signature (for example) makes sense in this case. This makes parsers smaller and faster, and requires more work on the higher-level logic. Generate an appropriate error message like 400 or 420, or if an extension if truly optional, maybe you can safely ignore it. Use your best judgement, and bring your code to the bakeoffs and try it out. thanks, -rohan > >Thank You >Rafi Assadi H.M. >Silicon Automation Systems >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 Jul 5 15:26:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15175 for ; Wed, 5 Jul 2000 15:26:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7B3C443B8; Wed, 5 Jul 2000 15:26:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 968A544341 for ; Wed, 5 Jul 2000 15:26:09 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA16080; Wed, 5 Jul 2000 15:26:08 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA20933; Wed, 5 Jul 2000 15:26:08 -0400 (EDT) Message-ID: <39638BD0.725AFDA@cs.columbia.edu> Date: Wed, 05 Jul 2000 15:26:08 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jacobus Alberts Cc: "Sip List (E-mail)" Subject: Re: [SIP] SIPURL IPv6 address possibly incorrect References: <934C10A9A64AD4119440009027E0998801C45E@MAIL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jacobus Alberts wrote: > > Hello > > My apologies if what I am about to raise has already been covered somewhere > else in this list, but I have briefly checked, I do not think so. > > I believe that the ABNF for the IPv6Address is incorrect. In RFC2373, an > extra element is defined as > IPv6prefix = hexpart "/" 1*2DIGIT and then subsequently, > IPv6address = IPv6prefix [":" IPv4address] I'm not sure what edition of RFC 2373 you are reading, but mine reads in Appendix B: IPv6address = hexpart [ ":" IPv4address ] IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6prefix = hexpart "/" 1*2DIGIT hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG which is exactly what's in the SIP I-D. > > The above definition is more sensible to me, since ":" can occur in the > hexpart. If the definition from the RFC2543 is used, hexpart replaces > IPv6prefix above. Then it would be impossible to distinguish between a ":" > in the hexpart or the ":" delimiting the optional IPv4address (should you > want to parse such that IPv4address could be extracted of course!) I don't understand. IPv6prefix is not used for addresses, only for address prefixes, such as 12AB:0:0:CD3/60 (see pg. 5 of RFC 2733) Just like 12.1.0.0/16 would never appear in an URL, the IPv6 prefix wouldn't either. > > Have I missed some comment in the RFC regarding this? Or is the issue > raised valid? > > Jacobus Alberts > > Azisa (Pty) Ltd > email: jalberts@azisa.co.za > > _______________________________________________ > 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 Jul 5 15:34:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15313 for ; Wed, 5 Jul 2000 15:34:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B16B4443BA; Wed, 5 Jul 2000 15:33:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 86319443B0 for ; Wed, 5 Jul 2000 15:33:54 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA16528; Wed, 5 Jul 2000 15:33:53 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA21679; Wed, 5 Jul 2000 15:33:52 -0400 (EDT) Message-ID: <39638DA0.ED1A5A7E@cs.columbia.edu> Date: Wed, 05 Jul 2000 15:33:52 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: antti.vaha-sipila@nokia.com Cc: gethin@ubiquity.net, sip@lists.bell-labs.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: <6D1A8E7871B9D211B3B00008C7490AA502F53E82@treis03nok> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit antti.vaha-sipila@nokia.com wrote: > > Hello, > > > > Modified spec roughly accordingly. Note that RFC 2806 has a mistake in > > that % can never appear as itself. Same for %22 (") and %23 > > (#), %3c (<) > > and %3e (>), according to RFC 2396. > > Are you referring to here? > > Yes, this is mentioned in RFC 2806 section 1.2. All of those chars must be > escaped before using them in a tel: URL. This is also said in the BNF > comments. The original reason why I listed the characters exclipitly in > was that there were some characters that should not be > present as the first character of the prefix, to make it distinguishable > from and after unescaping. However, this notation is very confusing and at variance with RFC 2396. Characters that can't appear by themselves (without escaping) should just be listed as "escaped", not be listed as octets. If there are certain characters that somehow designate number ranges, this is not really a BNF issue. (Whether this is a good idea is a separate topic; in my view, relying on naming rules that omit characters, but otherwise look identical, to determine semantics is likely to be confusing. I think it would be much cleaner to designate some special character as a private prefix, e.g., *) > > (I do not subscribe to SIP mailing list at the moment, so please Cc: me on > replies - thanks.) > > Antti > > -- > Antti Vähä-Sipilä / Nokia Mobile Phones > My views and opinions are not necessarily those of my employer. > Send personal email to avs@iki.fi only. http://www.iki.fi/avs/ > > _______________________________________________ > 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 Jul 5 15:37:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15374 for ; Wed, 5 Jul 2000 15:37:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CEC7443C7; Wed, 5 Jul 2000 15:37:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id C9EFA443C5 for ; Wed, 5 Jul 2000 15:37:34 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA17658; Wed, 5 Jul 2000 12:37:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA09856; Wed, 5 Jul 2000 12:37:01 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14691.36445.482635.940569@thomasm-u1.cisco.com> Date: Wed, 5 Jul 2000 12:37:01 -0700 (PDT) To: Jonathan Rosenberg Cc: Henning Schulzrinne , Sean Olson , Adam.Roach@Ericsson.com, rohan@cisco.com, oran@cisco.com, rfairlie@nuera.com, sip@lists.bell-labs.com Subject: Re: [SIP] Static Images In-Reply-To: <3962B71A.62941794@dynamicsoft.com> References: <200006291657.LAA10490@b04a45.exu.ericsson.se> <395D6FE1.D0D7EFC8@dynamicsoft.com> <395DF21E.BC68B052@cs.columbia.edu> <3962B71A.62941794@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > Henning Schulzrinne wrote: > > I agree, but would tend to view semantic equivalence as somewhat more > > limited. For example, I don't think that error indication, ringing > > indication and additional information about caller/callee can just all > > be rendered if I don't recognize the purpose tag. > > This is the big issue. My proposal is that this header be ONLY for > things which can be reasonably rendered without knowing the semantic > content. I think this includes things like jpeg/vcards for caller ID, > for example, but not distinctive ringing, as you point out. I continue to feel that inlining content is just a really awful idea. The slippery slope you mention here is one reason, but the thing that really bugs me is the MTU issue for UDP. The thought of SIP regularly transmitting fragments so that you can see somebody's mug seems like a fundamentally broken idea. Also: I'm not sure how you'd break larger content across messages. Another thing that pretty much sucks is that if the content is shipped through proxies, you be putting an awful lot of extra transaction load on the proxies who would have to do useless fragmentation kruft (from their vantage). I know that Henning is likely to chime in here extolling the virtues of TCP, but UDP is a valid transport for SIP, and in some ways limited MTU is a sanity check for those who would like to use SIP as a kitchen sink transport. If we have to do this at all, what's wrong with multipart mime? Isn't there a way with mime to ship fragments of content already? Better yet: URL's are your friends. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 15:48:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15540 for ; Wed, 5 Jul 2000 15:48:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 36401443D2; Wed, 5 Jul 2000 15:47:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id AB746443B0 for ; Wed, 5 Jul 2000 15:47:39 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA17334; Wed, 5 Jul 2000 15:47:38 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA22362; Wed, 5 Jul 2000 15:47:38 -0400 (EDT) Message-ID: <396390DA.1FD0CD55@cs.columbia.edu> Date: Wed, 05 Jul 2000 15:47:38 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Jonathan Rosenberg , Sean Olson , Adam.Roach@Ericsson.com, rohan@cisco.com, oran@cisco.com, rfairlie@nuera.com, sip@lists.bell-labs.com Subject: Re: [SIP] Static Images References: <200006291657.LAA10490@b04a45.exu.ericsson.se> <395D6FE1.D0D7EFC8@dynamicsoft.com> <395DF21E.BC68B052@cs.columbia.edu> <3962B71A.62941794@dynamicsoft.com> <14691.36445.482635.940569@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Jonathan Rosenberg writes: > > Henning Schulzrinne wrote: > > > I agree, but would tend to view semantic equivalence as somewhat more > > > limited. For example, I don't think that error indication, ringing > > > indication and additional information about caller/callee can just all > > > be rendered if I don't recognize the purpose tag. > > > > This is the big issue. My proposal is that this header be ONLY for > > things which can be reasonably rendered without knowing the semantic > > content. I think this includes things like jpeg/vcards for caller ID, > > for example, but not distinctive ringing, as you point out. > > I continue to feel that inlining content is just a Before this gets another discussion started: Inlining is *not* suggested. Just URLs. Something like Call-Info: [If you *really* want to inline, the data: URL can do that, too, but I didn't say that.] That's what in the current edition of RFC2543bis. -- 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 Jul 5 15:52:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15615 for ; Wed, 5 Jul 2000 15:52:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 03128443D6; Wed, 5 Jul 2000 15:52:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 02C7B443C3 for ; Wed, 5 Jul 2000 15:52:28 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA19273; Wed, 5 Jul 2000 12:52:38 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA09859; Wed, 5 Jul 2000 12:52:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14691.37372.424910.359833@thomasm-u1.cisco.com> Date: Wed, 5 Jul 2000 12:52:28 -0700 (PDT) To: "Gardell, Steve" Cc: "'Jonathan Rosenberg'" , Serban Tatu , siplist Subject: RE: [SIP] authentication at gateway 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Gardell, Steve writes: > > So, upon receiving the 401, the gateway performs some local > > operation to > > get the username and password. Perhaps it plays out an > > announcement and > > collects the username/password; perhaps they are simply established > > ahead of time and stored in a database - the gateway just fetches them > > when prompted for authentication. > > > > > A practical issue with this approach is that gateways are often > deployed in support of many different services that may have > different authentication requirements. Placing all of the > authentication smarts in the gateway makes it difficult to roll > out new services. Now admittedly this is a "telco centric" view > of the service world - I suggest that the appropriate "converged" > architecture is to have authentication controlled from outside > the gateway and to implement it via a SIP Proxy(like?) element in > situations where we want the core service to be agnostic as to whether > the endpoint is a gateway or a UA. Maybe I'm misunderstanding, but I'd think that the *inability* to authenticate an untrusted UA would be a major impediment to deploying new services; spoofing attacks are far too easy. Also: I guess I don't understand why you think that building some sort of security proxy would be easier than just building in end to end security. From what I've seen, they are mainly hacks to get around things that can't do end to end security themselves, but they add a lot of overall complexity since they're essentially second guessing what an application should have done with all of the disadvantages of being a bump in the wire. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 15:55: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 ESMTP id PAA15651 for ; Wed, 5 Jul 2000 15:55:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D2E9D443DD; Wed, 5 Jul 2000 15:54:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id EE346443C0 for ; Wed, 5 Jul 2000 15:54:42 -0400 (EDT) Received: from ORANLT (oran-home-ss20.cisco.com [171.69.210.4]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id MAA02889; Wed, 5 Jul 2000 12:54:07 -0700 (PDT) From: "David Oran" To: Date: Wed, 5 Jul 2000 15:54:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: [SIP] NPR report on new phone services Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Morning Edition June 28, 2000 http://search.npr.org/cf/cmn/cmnpd01fm.cfm?PrgDate=06/28/2000&PrgID=3 New Phone Services Vie the Traditional NPR's Jack Speer reports that wireless and Internet phone services are pressing traditional long-distance service rates downwards. Major long-distance providers may have to lower their rates to compete with companies that offer long-distance at a flat rate, or even for free. (5:14) 14.4 kbps http://www.npr.org/ramfiles/me/20000628.me.07.ram 28.8 kbps http://www.npr.org/ramfiles/me/20000628.me.07.rmm Requires the RealAudio Player http://www.npr.org/inside/realaudio.html The report explains that data is surpassing voice, and that long distance prices are moving toward zero, but average U.S. family total spending on communications increased from $325 in 1980 to $830 in 1998. Includes commentary on AT&T business shifts and recording of free telephone conversation over Dialpad.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 Jul 5 17:50:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17677 for ; Wed, 5 Jul 2000 17:50:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A2D94439D; Wed, 5 Jul 2000 17:49:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.idc1.level3.com (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 5C9DC44341 for ; Wed, 5 Jul 2000 17:49:28 -0400 (EDT) Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140]) by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id VAA21696; Wed, 5 Jul 2000 21:49:23 GMT From: Jon.Peterson@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id PAA07746; Wed, 5 Jul 2000 15:49:22 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jul 2000 15:51:03 -0600 Message-ID: <87A245E94948D3118DE30008C716B01301523A02@c0005v1idc1.oss.level3.com> To: Gonzalo.Camarillo@lmf.ericsson.se Cc: sip@lists.bell-labs.com Subject: RE: [SIP] QoS & Third Party Call Control in SIP Date: Wed, 5 Jul 2000 15:49:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com My $.02: In the case of some services, it makes sense for C to send A a 'holding' SDP (directing c= to 0.0.0.0) in the first INVITE rather than omitting SDP entirely. Mostly, these are services for which it is likely that A will perceive a long hiatus between the transmission of its 200 message to C and the receipt of an ACK (I think C could want to wait until A picks up, 200 as opposed to 18x, before ringing B, hence the possibility of a gap here). Now, of course, one could send a=qos preconditions in this holding SDP, but obviously without B's SDP this will not enable A to send any resource reservation signals. What it -does- allow is for C to send an immediate ACK to A, and then re-INVITE A later with the qos preconditions and B's media characteristics. This should be compatible with your flow below, in which B has already reserved resources. Note that this assumes that it is acceptable for A's user to pick up the phone without any guarantee that B can be reached, or that QoS is guaranteed. I believe that the 3pcc mechanism behaves this way in a number of cases, and that it may not, in fact, be undesirable for certain services. Hopefully, the service provider that controls C will offer some sort of feedback to A's user (perhaps through a media stream announcement, or other out-of-band means when applicable) to mitigate any dead air this mechanism could cause. Jon Peterson Level(3) Communications -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Wednesday, July 05, 2000 6:21 AM To: sip; schulzrinne@cs.columbia.edu; jdrosen@dynamicsoft.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP Hi, Some folks have pointed out that this is a similar problem to the one DCS was trying to solve using the double-stage INVITE. This is actually true, but I do not like the double-stage INVITE approach. In the following example C will be the 3rd party, and the media session will be established between A and B: C sends an INVITE to A without SDP (issue: how can C state that QoS will be needed if there is not SDP in the INVITE?) A responds with 183 with a SDP. C sends an INVITE to B with the SDP received from A. We can specify QoS preconditions here. B responds with 183 with its SDP and begin performing resource reservation in the path B->A How can now C send B's SDP to A?? If A does not have B's SDP it cannot perform resource reservation in the path A->B... Can we re-INVITE A at this stage? Thanks, Gonzalo Gonzalo Camarillo wrote: > > Hi, > > The draft "Third Party Call Control in SIP", which can be found at > http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt > > outlines a method for establishing a session between two hosts that have > signalling (SIP) relationships with a 3rd host that is not involved in > the session. > > The idea is basically to send an INVITE to A-party without SDP and then > send the SDP coming from the B-party in the ACK. > > This works fine when no QoS is needed. If preconditions must be used > this method fails. Preconditions cannot be added to the SDP in the ACK, > since ACKs trigger no responses. > > Both parties involved in the session have to know both SDP descriptions > in order to perform resource reservation (with RSVP, for instance). > Then, COMET will have to be sent. > > Have somebody taken this into account regarding this draft? Any ideas? > > 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 > > _______________________________________________ > 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/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 Jul 5 17:50:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17689 for ; Wed, 5 Jul 2000 17:50:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 888D9443C2; Wed, 5 Jul 2000 17:50:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id B6E4844341 for ; Wed, 5 Jul 2000 17:50:29 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id RAA24264; Wed, 5 Jul 2000 17:50:00 -0400 (EDT) Message-ID: <01c301bfe6cb$73746260$3102a8c0@broadsoft.com> From: "Brett Tate" To: "rafi" , "Rohan Mahy" Cc: References: <4.2.0.58.20000705102221.01b55100@lint.cisco.com> Subject: Re: [SIP] Few doubts Date: Wed, 5 Jul 2000 17:53:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Rohan Mahy To: rafi Cc: Sent: Wednesday, July 05, 2000 2:02 PM Subject: Re: [SIP] Few doubts > At 02:26 AM 7/5/00 , rafi wrote: > > > > Hi, > > > > > > > > (i) What should be the action of a SIP entity when it receives a > > message > > in which one or more mandatory parameters are missing ? > > Send an apropos error, ex: 400 Bad Request. > In general, I agree that 400 Bad Request should be sent. However since the Call-ID, CSeq, To, and From are all used to match up a response to a request, I'd recommend not sending back anything without at least these fields. Also, where should the response be sent when the Via is not present? > > > (ii) When UAS ( section 4.2.1) receives another INVITE message before > > it has sent the final response to the first INVITE then it > > returns a 400 > > response and includes a Retry-After field with randomly chosen > > value. > > My question is if a random value is to be filled in Retry- After > > field then > > why this header field is a MUST ? Why can't UAC itself choose > > random value and resend the INVITE message ? > > This late in SIP's development, WHY questions are sort of futile. The > correct answer at this point is because a) lots of people implemented it > that way, and b) it works. I'm sure if you are curious you can dredge > through the mailing list archives for the answer. It could be a very good > reason, or it could be arbitrary (I don't know), but as long as the > mechanism works, who cares! > > > > > (iii) Many Regular expressions does not prohibit the case > > of repetition (it is a > > limitation rather). For eg, > > > > Authorization: pgp signature = "xxxx.." signature = "yyyyy...." > > > > is valid according to the grammar. In fact there are many places > > where these > > things can happen. What should be the action of SIP entity in > > such cases ? > > Unlike ASN.1 and DTDs, ANBF doesn't deal with repetition. You have to use > the semantics and common sense to tell you that only one signature (for > example) makes sense in this case. This makes parsers smaller and faster, > and requires more work on the higher-level logic. > > Generate an appropriate error message like 400 or 420, or if an extension > if truly optional, maybe you can safely ignore it. Use your best > judgement, and bring your code to the bakeoffs and try it out. > > thanks, > -rohan > > > > >Thank You > >Rafi Assadi H.M. > >Silicon Automation Systems > >Bangalore, INDIA > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 5 18:02:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17799 for ; Wed, 5 Jul 2000 18:02:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F08C443AE; Wed, 5 Jul 2000 18:02:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 370134436D for ; Wed, 5 Jul 2000 18:02:35 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FX800K01VW9XU@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 5 Jul 2000 22:02:33 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FX800J4GVW9QR@firewall.mcit.com>; Wed, 05 Jul 2000 22:02:33 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0FX800M01VW9HI@dgismtp02.wcomnet.com>; Wed, 05 Jul 2000 22:02:33 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FX800M01VW2GC@dgismtp02.wcomnet.com>; Wed, 05 Jul 2000 22:02:33 +0000 (GMT) Received: from C25776A ([166.44.137.9]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0FX800KI5VSL9O@dgismtp02.wcomnet.com>; Wed, 05 Jul 2000 22:02:24 +0000 (GMT) Date: Wed, 05 Jul 2000 17:01:50 -0500 From: Henry Sinnreich Subject: RE: [SIP] authentication at gateway In-reply-to: To: "Gardell, Steve" , "'Jonathan Rosenberg'" , Serban Tatu Cc: siplist Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit >I suggest that the appropriate >"converged" >architecture is to have authentication controlled from outside >the gateway and to implement it via a SIP Proxy(like?) >element in >situations where we want the core service to be >agnostic as to whether >the endpoint is a gateway or a UA. Exactly right! Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >Gardell, Steve >Sent: Wednesday, July 05, 2000 6:42 AM >To: 'Jonathan Rosenberg'; Serban Tatu >Cc: siplist >Subject: RE: [SIP] authentication at gateway > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> Sent: Wednesday, July 05, 2000 12:01 AM >> To: Serban Tatu >> Cc: siplist >> Subject: Re: [SIP] authentication at gateway >> >> >> THe most likely scenario is one you left out: the >prompting and >> collection for the PIN are all performed by the originating >> gateway. In >> general, the entity demanding authentication will >not know that the >> request is through a gateway. I believe its unlikely >the entity would >> return 200 OK, or even a 401 with content. Rather, >just a 401. >> >> So, upon receiving the 401, the gateway performs some local >> operation to >> get the username and password. Perhaps it plays out an >> announcement and >> collects the username/password; perhaps they are >simply established >> ahead of time and stored in a database - the gateway >just fetches them >> when prompted for authentication. >> > > >A practical issue with this approach is that gateways are often >deployed in support of many different services that may have >different authentication requirements. Placing all of the >authentication smarts in the gateway makes it difficult to roll >out new services. Now admittedly this is a "telco centric" view >of the service world - I suggest that the appropriate >"converged" >architecture is to have authentication controlled from outside >the gateway and to implement it via a SIP Proxy(like?) >element in >situations where we want the core service to be >agnostic as to whether >the endpoint is a gateway or a UA. > > >> -Jonathan R. >> >> Serban Tatu wrote: >> > >> > Hi, >> > >> > How is authentication performed by a SIP-enabled gateway? >> Let's say somebody on >> > a PSTN phone wants to gain access to a service and >> therefore has to provide a >> > username/password. Some scenarios come to mind >(newbie >> > here): >> > >> > Scenario 1 (smart gateway): >> > >> > - SIP UAS at service side sends a 401 unauthorized as a >> response to the INVITE. >> > The response contains a voice prompt audio file (e.g. >> Gimme >> > username/password). >> > - gateway is so smart that it knows how to play the prompt >> and collect DTMF >> > tones representing username and password, which it then >> sends back encoded >> > somehow to the service. >> > >> > Scenario 2 (not so smart gateway): >> > >> > - SIP UAS at service side sends back a 200 OK response to >> the INVITE. The >> > response contains the voice prompt as before. >> > - gateway knows how to play the audio file, sends ACK, >> media connections are >> > open. >> > - SIP UAS at service side then sends an INFO >message with a >> DTMF collection >> > scheme (voice prompt could also be sent here). >> > - gateway collects the tones and sends them back with >> another INFO message. >> > >> > Scenario 3 (dumb gateway): >> > >> > - SIP UAS at service side sends back a 200 OK response to >> the INVITE. >> > - gateway and SIP UAS establish their media channels. >> > - service then plays the whole authentication scenario >> through the media >> > channels. Gateway lets DTMF tones flow through the >media path. >> > >> > Do any of these scenarios make any sense? It seems to me >> that 1 and 2 are sci-fi >> > given the current gateway solutions, while 3 might not be >> possible because the >> > gateway grabs the DTMF tones, or if it doesn't >then it's an >> ugly solution since >> > signaling and media are all mixed together. >> > >> > Thanks, >> > Serban >> >> -- >> Jonathan D. Rosenberg 72 Eagle >Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East >Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: >(973) 952-5050 >> http://www.cs.columbia.edu/~jdrosen PHONE: >(732) 741-7244 >> http://www.dynamicsoft.com >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 22: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 ESMTP id WAA23479 for ; Wed, 5 Jul 2000 22:44:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 98F824439A; Wed, 5 Jul 2000 22:43:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id A08DF44341 for ; Wed, 5 Jul 2000 22:43:35 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jul 2000 19:44:39 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Gethin Liddell'" , Henning Schulzrinne Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Wed, 5 Jul 2000 19:44:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Gethin, > > @ is not allowed in parameters. Therefore it would be possible to > delimit the userinfo first by looking for @ and then parsing the host > afterwards so in the case above (assuming the ; and ? hasve been added > to the user bnf), this can only be resolved as > > user = ABCD;dog=cat > host = fish.com > I think you misinterpreted my example (the parameter cat=dog originated as a tel: prameter not a sip one; however it may be interpreted as a SIP parameter dog=cat@fish.com - that's the ambiguity). sip:ABCD;dog=cat@fish.com;user=phone From RFC2543bis (July 2000) the @ is a valid SIP parameter value (see below). So if the parser doesn't understand the user=phone parameter (or is not very careful in handling the tel:) then it WILL be misinterpreted!!! See what I mean about this making the SIP URL parsing complicated and conditional on the understanding of a parameter value !!! other-param = pname - pname "=" pvalue (Henning, I assume that is supposed to be a '|' not a hyphen in the document, right ?). pname = 1 * paramchar pvalue = 1 * paramchar paramchar = param-unreserved | unreserved | escaped param-unreserved = [ | ] | / | : | @ | & | + | $ > > If the parser determines the end of the user@host:port by > searching for a > > semicolon then the same thing will occur. This is a valid > (as far as I can > > see) and simple way for parser to pull out the base URL (until now). > > do you mean searching for a question mark here? If you do > then i agree > this is a problem. Slightly modifying your example (whether > there is a > user parameter or not does not matter): > No. I am simply anticipating how some parsers might currently work. sip:user@host:port;option1=optionval;etc=etcval An easy way to retrieve the user@host:port section is to search for the first semicolon (or end of string or closing angle bracket '>'). Placing a semicolon in the user part will confuse them. > > > Slightly kludgier but at least syntactically workable would be to > > differently quote the meta characters in the tel:. > > or remove @ from the list of characters in headers and make it have to > be escaped. > So we hack/simplify things by removing the @ character from headers so that we can place the ; in the user part?? Doesn't sound like a good trade off to me. > But it is not backwards compatible at all If an old parser sees %%3b > then it will not correctly parse it anyway. I don't really > like adding > and removing characters from the BNF but I think it is preferable to > adding a new escaping mechanism that will make things fuzzier and more > complicated. Ok ok ... I knew I should have suggested an alternate quoting mechanism from the outset. The translation may make conversion of the telephone-subscriber ever so slightly more complicated but at least the complication and changes are localized to just this area (and not pushed to complicating the whole SIP URL parsing). One of the simplest methods would be to translate the tel: reserved characters ';' & '?' to two other URI reserved characters (RFC2396) that are unreserved characters in the SIP user part. '&', '$' and '/' fulfill these conditions. So simply translate ; to & and ? to $. Something a little more idiot proof is to translate them to something longer, eg: ; to /%3b/ ? to /%3f/ See any problems ? Got any objections or preference ? 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 Jul 5 22:49:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23511 for ; Wed, 5 Jul 2000 22:49:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5AD84443C0; Wed, 5 Jul 2000 22:48:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 58B76443AE for ; Wed, 5 Jul 2000 22:48:40 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id VAA23924; Wed, 05 Jul 2000 21:50:56 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Jul 2000 21:45:53 -0500 Message-ID: From: "Culpepper, Bert" To: Henry Sinnreich , "Gardell, Steve" , "'Jonathan Rosenberg'" , Serban Tatu Cc: siplist Subject: RE: [SIP] authentication at gateway Date: Wed, 5 Jul 2000 21:45:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com My study of gateway capabilities has not revealed an answer to Serban's question other than that authentication (via the scenarios described) is not available in gateways today and is not likely to show up anytime soon if at all. IMO, the most likely solution is very much like #3 for the scenario given. An MCGP or Megaco compliant gateway can collect and report DTMF digits in signaling separate from the media. However, this requires the SIP UAS to also "speak" one of these protocols (obviously, not a good solution at all). In networks where PSTN phones are served there is also likely to be a Gateway Controller that provides an interface between the gateway and SIP UA. A practical and feasible approach is to extend the gateway's MGCP/Megaco-based event detection and reporting to SIP UAs (for which at least one solution has been proposed). The application-specific prompts can be provided by the application server and leave the gateway to performing its "gateway" functions. A SIP "only" (non MGCP/Megago specific) solution for PSTN-phone event detection and reporting (as has also been proposed) would allow the service to be agnostic to the endpoint type but may not map to MGCP and Megaco. Maybe we'll see a solution in the near future for all terminals (SIP, PSTN, others?). Bert -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com] Sent: Wednesday, July 05, 2000 6:02 PM To: Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu Cc: siplist Subject: RE: [SIP] authentication at gateway >I suggest that the appropriate >"converged" >architecture is to have authentication controlled from outside >the gateway and to implement it via a SIP Proxy(like?) >element in >situations where we want the core service to be >agnostic as to whether >the endpoint is a gateway or a UA. Exactly right! Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >Gardell, Steve >Sent: Wednesday, July 05, 2000 6:42 AM >To: 'Jonathan Rosenberg'; Serban Tatu >Cc: siplist >Subject: RE: [SIP] authentication at gateway > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> Sent: Wednesday, July 05, 2000 12:01 AM >> To: Serban Tatu >> Cc: siplist >> Subject: Re: [SIP] authentication at gateway >> >> >> THe most likely scenario is one you left out: the >prompting and >> collection for the PIN are all performed by the originating >> gateway. In >> general, the entity demanding authentication will >not know that the >> request is through a gateway. I believe its unlikely >the entity would >> return 200 OK, or even a 401 with content. Rather, >just a 401. >> >> So, upon receiving the 401, the gateway performs some local >> operation to >> get the username and password. Perhaps it plays out an >> announcement and >> collects the username/password; perhaps they are >simply established >> ahead of time and stored in a database - the gateway >just fetches them >> when prompted for authentication. >> > > >A practical issue with this approach is that gateways are often >deployed in support of many different services that may have >different authentication requirements. Placing all of the >authentication smarts in the gateway makes it difficult to roll >out new services. Now admittedly this is a "telco centric" view >of the service world - I suggest that the appropriate >"converged" >architecture is to have authentication controlled from outside >the gateway and to implement it via a SIP Proxy(like?) >element in >situations where we want the core service to be >agnostic as to whether >the endpoint is a gateway or a UA. > > >> -Jonathan R. >> >> Serban Tatu wrote: >> > >> > Hi, >> > >> > How is authentication performed by a SIP-enabled gateway? >> Let's say somebody on >> > a PSTN phone wants to gain access to a service and >> therefore has to provide a >> > username/password. Some scenarios come to mind >(newbie >> > here): >> > >> > Scenario 1 (smart gateway): >> > >> > - SIP UAS at service side sends a 401 unauthorized as a >> response to the INVITE. >> > The response contains a voice prompt audio file (e.g. >> Gimme >> > username/password). >> > - gateway is so smart that it knows how to play the prompt >> and collect DTMF >> > tones representing username and password, which it then >> sends back encoded >> > somehow to the service. >> > >> > Scenario 2 (not so smart gateway): >> > >> > - SIP UAS at service side sends back a 200 OK response to >> the INVITE. The >> > response contains the voice prompt as before. >> > - gateway knows how to play the audio file, sends ACK, >> media connections are >> > open. >> > - SIP UAS at service side then sends an INFO >message with a >> DTMF collection >> > scheme (voice prompt could also be sent here). >> > - gateway collects the tones and sends them back with >> another INFO message. >> > >> > Scenario 3 (dumb gateway): >> > >> > - SIP UAS at service side sends back a 200 OK response to >> the INVITE. >> > - gateway and SIP UAS establish their media channels. >> > - service then plays the whole authentication scenario >> through the media >> > channels. Gateway lets DTMF tones flow through the >media path. >> > >> > Do any of these scenarios make any sense? It seems to me >> that 1 and 2 are sci-fi >> > given the current gateway solutions, while 3 might not be >> possible because the >> > gateway grabs the DTMF tones, or if it doesn't >then it's an >> ugly solution since >> > signaling and media are all mixed together. >> > >> > Thanks, >> > Serban >> >> -- >> Jonathan D. Rosenberg 72 Eagle >Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East >Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: >(973) 952-5050 >> http://www.cs.columbia.edu/~jdrosen PHONE: >(732) 741-7244 >> http://www.dynamicsoft.com >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 23:19:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23667 for ; Wed, 5 Jul 2000 23:19:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93CF1443AE; Wed, 5 Jul 2000 23:19:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 519B844341 for ; Wed, 5 Jul 2000 23:18:58 -0400 (EDT) Received: from dynamicsoft.com (1Cust141.tnt1.freehold.nj.da.uu.net [63.17.113.141]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA09138; Wed, 5 Jul 2000 23:20:00 -0400 (EDT) Message-ID: <3963FB23.C7FD1D53@dynamicsoft.com> Date: Wed, 05 Jul 2000 23:21:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pathangi N Janardhanan Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Usages References: <002401bfe65d$b6cb7f80$38c9a8c0@labs> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Pathangi N Janardhanan wrote: > > Hi, > > Is there any document or paper which talks about the various > applications that > can be build for the SIP protocol. > > Some of the ones are > > a) use of SIP for VoIP terminal This is the primary application of SIP and well discussed in the specification itself, in addition to almost any paper or presentation you might find at: http://www.cs.columbia.edu/~hgs/sip > b) Use of SIP for MGC to MGC communication See the various SIP-T drafts, of which you mention just one: http://www.softarmor.com/sipwg/drafts/draft-zimmerer-sip-bcp-t-00.txt http://www.softarmor.com/sipwg/drafts/draft-zimmerer-sip-isup-mime-01.txt http://www.softarmor.com/sipwg/drafts/draft-watson-sip-isup-mime-00.txt http://www.softarmor.com/sipwg/drafts/draft-camarillo-sip-isup-bcp-00.txt I also have some slides on this subject: http://www.cs.columbia.edu/~jdrosen/papers/vondev_intermgc_final.ppt > > The draft "draft-ietf-sip-isup-mime" talks of carrying ISUP/QSIG > messages in SIP messages, > where would such a need be felt. For tunneling ISUP/QSIG messages > would SIGTRAN not > be a better approach? Not if you want to derive call control from SIP itself, in order to access features available from SIP, or talk to endpoints for which you don't know apriori that they are another ss7 connected softswitch. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 5 23:57:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24427 for ; Wed, 5 Jul 2000 23:57:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1074A443CF; Wed, 5 Jul 2000 23:56:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9C76544341 for ; Wed, 5 Jul 2000 23:56:50 -0400 (EDT) Received: from dynamicsoft.com (1Cust141.tnt1.freehold.nj.da.uu.net [63.17.113.141]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA09156; Wed, 5 Jul 2000 23:58:15 -0400 (EDT) Message-ID: <39640415.AB872291@dynamicsoft.com> Date: Wed, 05 Jul 2000 23:59:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: Henry Sinnreich , "Gardell, Steve" , Serban Tatu , siplist Subject: Re: [SIP] authentication at gateway References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit You are merging a bunch of issues here which are really separate. I agree that each service will have its own means of authenticating users of that service. SIP already provides three ways of obtaining authentication for requests - http basic, http digest, and pgp. If the service wishes to use these mechanisms to authenticate subscribers, than that is its decision. If the entity acting as UAC (gateway or softswitch) cannot obtain information required to provide credentials, then users through that gateway can't access those services. If an application wishes to authenticate through a media conversation, this is also its choice. Doing so works just fine now with SIP, by collecting DTMF or doing speech recognition or whatever, as part of the media stream, using 183, for example, to establish early media. This will alleviate the gateway from the "burden" of authentication from each service, as requested, and do so in a manner which works for gateways, PC clients, IP phones, or whatever, in a uniform fashion. These mechanisms are not all that secure in reality (remember, this ain't the PSTN anymore), but thats also a separate issue. It is a separate and orthogonal issue as to whether the DTMF is carried within SIP, and orthogonal and separate once again about whether SIP UAs need to speak megaco in order to be controlled by a device providing services. I have many comments on this issue, and it is on my todo list to collect them and respond to the earlier thread on the subject. In any case most of you can guess my feelings on mandating megaco in a SIP UA in order to access services. -Jonathan R. "Culpepper, Bert" wrote: > > My study of gateway capabilities has not revealed an answer to Serban's > question other than that authentication (via the scenarios described) is not > available in gateways today and is not likely to show up anytime soon if at > all. IMO, the most likely solution is very much like #3 for the scenario > given. An MCGP or Megaco compliant gateway can collect and report DTMF > digits in signaling separate from the media. However, this requires the SIP > UAS to also "speak" one of these protocols (obviously, not a good solution > at all). In networks where PSTN phones are served there is also likely to > be a Gateway Controller that provides an interface between the gateway and > SIP UA. A practical and feasible approach is to extend the gateway's > MGCP/Megaco-based event detection and reporting to SIP UAs (for which at > least one solution has been proposed). The application-specific prompts can > be provided by the application server and leave the gateway to performing > its "gateway" functions. A SIP "only" (non MGCP/Megago specific) solution > for PSTN-phone event detection and reporting (as has also been proposed) > would allow the service to be agnostic to the endpoint type but may not map > to MGCP and Megaco. > > Maybe we'll see a solution in the near future for all terminals (SIP, PSTN, > others?). > > Bert > > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com] > Sent: Wednesday, July 05, 2000 6:02 PM > To: Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu > Cc: siplist > Subject: RE: [SIP] authentication at gateway > > >I suggest that the appropriate > >"converged" > >architecture is to have authentication controlled from outside > >the gateway and to implement it via a SIP Proxy(like?) > >element in > >situations where we want the core service to be > >agnostic as to whether > >the endpoint is a gateway or a UA. > > Exactly right! > > Henry > > >-----Original Message----- > >From: sip-admin@lists.bell-labs.com > >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of > >Gardell, Steve > >Sent: Wednesday, July 05, 2000 6:42 AM > >To: 'Jonathan Rosenberg'; Serban Tatu > >Cc: siplist > >Subject: RE: [SIP] authentication at gateway > > > > > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >> Sent: Wednesday, July 05, 2000 12:01 AM > >> To: Serban Tatu > >> Cc: siplist > >> Subject: Re: [SIP] authentication at gateway > >> > >> > >> THe most likely scenario is one you left out: the > >prompting and > >> collection for the PIN are all performed by the originating > >> gateway. In > >> general, the entity demanding authentication will > >not know that the > >> request is through a gateway. I believe its unlikely > >the entity would > >> return 200 OK, or even a 401 with content. Rather, > >just a 401. > >> > >> So, upon receiving the 401, the gateway performs some local > >> operation to > >> get the username and password. Perhaps it plays out an > >> announcement and > >> collects the username/password; perhaps they are > >simply established > >> ahead of time and stored in a database - the gateway > >just fetches them > >> when prompted for authentication. > >> > > > > > >A practical issue with this approach is that gateways are often > >deployed in support of many different services that may have > >different authentication requirements. Placing all of the > >authentication smarts in the gateway makes it difficult to roll > >out new services. Now admittedly this is a "telco centric" view > >of the service world - I suggest that the appropriate > >"converged" > >architecture is to have authentication controlled from outside > >the gateway and to implement it via a SIP Proxy(like?) > >element in > >situations where we want the core service to be > >agnostic as to whether > >the endpoint is a gateway or a UA. > > > > > >> -Jonathan R. > >> > >> Serban Tatu wrote: > >> > > >> > Hi, > >> > > >> > How is authentication performed by a SIP-enabled gateway? > >> Let's say somebody on > >> > a PSTN phone wants to gain access to a service and > >> therefore has to provide a > >> > username/password. Some scenarios come to mind > >(newbie > >> > here): > >> > > >> > Scenario 1 (smart gateway): > >> > > >> > - SIP UAS at service side sends a 401 unauthorized as a > >> response to the INVITE. > >> > The response contains a voice prompt audio file (e.g. > >> Gimme > >> > username/password). > >> > - gateway is so smart that it knows how to play the prompt > >> and collect DTMF > >> > tones representing username and password, which it then > >> sends back encoded > >> > somehow to the service. > >> > > >> > Scenario 2 (not so smart gateway): > >> > > >> > - SIP UAS at service side sends back a 200 OK response to > >> the INVITE. The > >> > response contains the voice prompt as before. > >> > - gateway knows how to play the audio file, sends ACK, > >> media connections are > >> > open. > >> > - SIP UAS at service side then sends an INFO > >message with a > >> DTMF collection > >> > scheme (voice prompt could also be sent here). > >> > - gateway collects the tones and sends them back with > >> another INFO message. > >> > > >> > Scenario 3 (dumb gateway): > >> > > >> > - SIP UAS at service side sends back a 200 OK response to > >> the INVITE. > >> > - gateway and SIP UAS establish their media channels. > >> > - service then plays the whole authentication scenario > >> through the media > >> > channels. Gateway lets DTMF tones flow through the > >media path. > >> > > >> > Do any of these scenarios make any sense? It seems to me > >> that 1 and 2 are sci-fi > >> > given the current gateway solutions, while 3 might not be > >> possible because the > >> > gateway grabs the DTMF tones, or if it doesn't > >then it's an > >> ugly solution since > >> > signaling and media are all mixed together. > >> > > >> > Thanks, > >> > Serban > >> > >> -- > >> Jonathan D. Rosenberg 72 Eagle > >Rock Ave. > >> Chief Scientist First Floor > >> dynamicsoft East > >Hanover, NJ 07936 > >> jdrosen@dynamicsoft.com FAX: > >(973) 952-5050 > >> http://www.cs.columbia.edu/~jdrosen PHONE: > >(732) 741-7244 > >> http://www.dynamicsoft.com > >> > >> > >> _______________________________________________ > >> SIP mailing list > >> SIP@lists.bell-labs.com > >> http://lists.bell-labs.com/mailman/listinfo/sip > >> > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 00:19:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24649 for ; Thu, 6 Jul 2000 00:19:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DC6B8443C4; Thu, 6 Jul 2000 00:19:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id ED00B44348 for ; Thu, 6 Jul 2000 00:19:44 -0400 (EDT) Received: from dynamicsoft.com (1Cust141.tnt1.freehold.nj.da.uu.net [63.17.113.141]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA09173; Thu, 6 Jul 2000 00:15:50 -0400 (EDT) Message-ID: <39640839.73912D4D@dynamicsoft.com> Date: Thu, 06 Jul 2000 00:16:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Krishna G , sip@lists.bell-labs.com Subject: Re: [SIP] on directed pick up service References: <001a01bfe69d$beff2770$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > > Basically, a typical call flow for such a scenario would be: > > > > > > A --INVITE--> P B --INVITE--> C > > > --INVITE--> > > > <---180---- > > > <--RINGING- > > > (At this point, User 2 hears B ringing from C) > > > <--------REGISTER-------- > > > -----------200----------> > > > ----------INVITE--------> > > > <--------RINGING--------- > > > <----------200----------- > > > --CANCEL--> > > > (yada yada) > > > > > > (In the above case, P is a forking proxy that CANCELs pending > > > branches upon reception of a 200 response, and which also acts as > > > a Registrar.) > > > > *** Now how does C know that it has to send the REGISTER request to P? > > Blind faith. &:) > > But seriously, this is where things potentially break-down, or not. > Something like "Directed Pick-Up" (if indeed that is the correct > term) does require some sort of sane configuration/application. How is it done in the circuit switched world? After all, both phones need to be part of the same PBX for this to work. Well, both terminals are hard wired to the same PBX. You can think of that as the ultimate in hardcoded configuration. The same is true here. As Jo has correctly pointed out, the service works assuming that both phones are configured to use the same proxy server. Alex Hardisty writes: > 2) Directed call pick-up requires me to enter the number of the telephone > that is ringing, so am I entering the number of the UA or am I entering my > personal number? If the latter it's not Directed Call Pickup but Personal > User Mobility. What's the service definition here? The service definition is whatever you want it to be. We here at IETF don't specify services, but rather protocols to support services. If the service you want is something as close as possible to existing call pickup, you can do that. A terminal is typically associated with a number, and would register itself as the handler for that number: REGISTER sip:example.com SIP/2.0 To: sip:1234@example.com Contact: sip:1234@phone23827304-8762.example.com The phone for extension 4321 would normally send a similar registration: REGISTER sip:example.com SIP/2.0 To: sip:4321@example.com Contact: sip:4321@phone11223344556677.example.com when I am sitting at extension 4321, and hear 1234 ringing, and want to pick it up, I would dial the appropriate service code and then enter the extension I want to pick up. This would cause that phone to send an additional register: REGISTER sip:example.com SIP/2.0 To: sip:1234@example.com Contact: sip:4321@phone11223344556677.example.com Now, this terminal begins to ring also and I can pick it up. Note that the "smarts" for this service are actually distributed; some of it is in the UA (which needs to know to send registers formatted this way when implementing the directed pickup service), and some in the proxy (which is doing normal registrations). > One point I neglected to mention before was that this isn't > exactly the same as "Directed Pick-Up" (in my experience of the > term), anyway. P may send an additional INVITE to C, but that > doesn't mean that B stops ringing (indeed, I can imagine > situations where that would be completely undesirable -- > preemptively registering a holiday address, for example -- since > User 2's call would suddenly "disappear"). It's only once User 2 > picks up from C, that B _might_ stop ringing. Correct. Note however, that causing the original terminal to stop ringing can also be achieved with some additional smarts in the phones, sending an additional REGISTER to unregister the original address... -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 00: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 ESMTP id AAA24686 for ; Thu, 6 Jul 2000 00:22:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 26CA2443DC; Thu, 6 Jul 2000 00:22:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6D51644348 for ; Thu, 6 Jul 2000 00:21:56 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id JAA28839 for ; Thu, 6 Jul 2000 09:15:36 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 06 Jul 2000 09:15:34 +0000 (IST) Received: from localhost (srinath@localhost) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id JAA22271 for ; Thu, 6 Jul 2000 09:15:29 +0530 (IST) Date: Thu, 6 Jul 2000 09:15:24 +0530 (IST) From: A Srinath To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Via headers in responses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I have a doubt regarding via headers in responses. 1. Suppose that a UAS receives a request with a CONTACT header, then the response is sent to the address listed in the CONTACT header field. In that case should we copy the VIA headers on to the response. The problem in copying VIA is that the entity receiving the response uses the VIA header field to check if it is meant for itself, and discards the response if the first VIA does not contain its own address. Could someone enlighten me on this issue. 2. In the case of CONTACT if we have a URL differant from a SIP URL then how is it processed. Regards, Srinath A Silicon Automation Systems Phone: 5276100, 5276108 extn 4220 #1309, 10th Main, HAL III Stage Bangalore 560 008, 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 Jul 6 00: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 ESMTP id AAA24874 for ; Thu, 6 Jul 2000 00:27:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6BCFF443E0; Thu, 6 Jul 2000 00:26:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id BAAC944341 for ; Thu, 6 Jul 2000 00:26:34 -0400 (EDT) Received: from dynamicsoft.com (1Cust141.tnt1.freehold.nj.da.uu.net [63.17.113.141]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA09198; Thu, 6 Jul 2000 00:27:37 -0400 (EDT) Message-ID: <39640AFC.7C69DA7@dynamicsoft.com> Date: Thu, 06 Jul 2000 00:28:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: A Srinath Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Via headers in responses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit A Srinath wrote: > > Hi, > I have a doubt regarding via headers in responses. > > 1. Suppose that a UAS receives a request with a CONTACT header, then the > response is sent to the address listed in the CONTACT header field. No. Responses are always sent using the via headers, never Contact. Contact is used for sending subsequent requests. In > that case should we copy the VIA headers on to the response. Via headers are ALWAYS copied into the response. > > The problem in copying VIA is that the entity receiving the response uses > the VIA header field to check if it is meant for itself, and discards the > response if the first VIA does not contain its own address. Right, which is the desired behavior. > > Could someone enlighten me on this issue. > > 2. In the case of CONTACT if we have a URL differant from a SIP URL then > how is it processed. The contact URL in INVITE and 200 OK to invite MUST be a SIP URL, I believe, or things don't work. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 00:42:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25131 for ; Thu, 6 Jul 2000 00:42:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 394D3443A6; Thu, 6 Jul 2000 00:42:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 048DA44341 for ; Thu, 6 Jul 2000 00:42:24 -0400 (EDT) Received: from dynamicsoft.com (1Cust141.tnt1.freehold.nj.da.uu.net [63.17.113.141]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA09211; Thu, 6 Jul 2000 00:43:49 -0400 (EDT) Message-ID: <39640EC8.AC5B8D72@dynamicsoft.com> Date: Thu, 06 Jul 2000 00:44:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon.Peterson@Level3.com Cc: Gonzalo.Camarillo@lmf.ericsson.se, sip@lists.bell-labs.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP References: <87A245E94948D3118DE30008C716B01301523A02@c0005v1idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jon.Peterson@Level3.com wrote: > > My $.02: > > In the case of some services, it makes sense for C to send A a 'holding' SDP > (directing c= to 0.0.0.0) in the first INVITE rather than omitting SDP > entirely. Mostly, these are services for which it is likely that A will > perceive a long hiatus between the transmission of its 200 message to C and > the receipt of an ACK (I think C could want to wait until A picks up, 200 as > opposed to 18x, before ringing B, hence the possibility of a gap here). In many cases this holding approach makes sense. The new version of the 3pcc draft will contain a discussion of this issue. > > Now, of course, one could send a=qos preconditions in this holding SDP, but > obviously without B's SDP this will not enable A to send any resource > reservation signals. What it -does- allow is for C to send an immediate ACK > to A, and then re-INVITE A later with the qos preconditions and B's media > characteristics. This should be compatible with your flow below, in which B > has already reserved resources. Well, C can't send an ACK since there is no final response yet. It could include the update SDP in the PRACK, in which case you wouldn't need to do a re-INVITE. Its worth some discussion about whether PRACK can contain updated SDP; this sort of combines two very different functions into a single request (acknowledging a response and updating SDP). THen again, we've already combined those with normal ACK, so why not PRACK..? So, the call flow would look like: | INV (held SDP w/ preconditions) | | ----------------> | | | 183 SDP A | | | <---------------- | | | INV SDP A w/ preconditions | | ------------------+----------------> | | 183 SDP B | | | <-----------------+----------------- | | PRACK SDP B w/ preconditions | | ----------------->| | | PRACK | | | ------------------+----------------->| | 200 PRACK | | | <-----------------| | | | | | 200 PRACK | | |<------------------+------------------| | | | | COMET | | |<------------------| | | | | | COMET | | |<------------------+------------------| | | | | COMET | | |-----------------> | | | | | | COMET | | |-------------------+----------------->| | | | | | | | | | | | | | | | | | | | | | | | | | A C B Notice something very important here. The COMET need to be sent from the UAS back to the UAC. Thats because for the 3pcc case, C, which is the UAC for both INVITEs, does not have a way to know whether reservation was successful. I think the current manyfolks drafts says that the UAC only needs to send a COMET. We may need to rethink making this symmetric to support this 3pcc 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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 00:58:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25315 for ; Thu, 6 Jul 2000 00:58:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 79F0E443D7; Thu, 6 Jul 2000 00:58:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by lists.bell-labs.com (Postfix) with ESMTP id B9A4844341 for ; Thu, 6 Jul 2000 00:58:15 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id AAA05069; Thu, 6 Jul 2000 00:57:18 -0400 (EDT) Message-ID: <396411CB.238DDBE@cs.columbia.edu> Date: Thu, 06 Jul 2000 00:57:47 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'Gethin Liddell'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Simple solution: any @ should be reserved (and thus needs to be escaped) since it is syntactically significant in SIP URLs. (@ has no syntactic significance in RFC 2806 and thus this transformation is harmless.) Translating tel: URL delimiters into something else is really, really ugly and just cascades the problem. "Fairlie-Cuninghame, Robert" wrote: > > Gethin, > > > > @ is not allowed in parameters. Therefore it would be possible to > > delimit the userinfo first by looking for @ and then parsing the host > > afterwards so in the case above (assuming the ; and ? hasve been added > > to the user bnf), this can only be resolved as > > > > user = ABCD;dog=cat > > host = fish.com > > > > I think you misinterpreted my example (the parameter cat=dog originated as a > tel: prameter not a sip one; however it may be interpreted as a SIP > parameter dog=cat@fish.com - that's the ambiguity). > > sip:ABCD;dog=cat@fish.com;user=phone > > >From RFC2543bis (July 2000) the @ is a valid SIP parameter value (see > below). So if the parser doesn't understand the user=phone parameter (or is > not very careful in handling the tel:) then it WILL be misinterpreted!!! See > what I mean about this making the SIP URL parsing complicated and > conditional on the understanding of a parameter value !!! > > other-param = pname - pname "=" pvalue (Henning, I assume that is supposed > to be a '|' not a hyphen in the document, right ?). > pname = 1 * paramchar > pvalue = 1 * paramchar > paramchar = param-unreserved | unreserved | escaped > param-unreserved = [ | ] | / | : | @ | & | + | $ > > > > If the parser determines the end of the user@host:port by > > searching for a > > > semicolon then the same thing will occur. This is a valid > > (as far as I can > > > see) and simple way for parser to pull out the base URL (until now). > > > > do you mean searching for a question mark here? If you do > > then i agree > > this is a problem. Slightly modifying your example (whether > > there is a > > user parameter or not does not matter): > > > > No. I am simply anticipating how some parsers might currently work. > > sip:user@host:port;option1=optionval;etc=etcval > > An easy way to retrieve the user@host:port section is to search for the > first semicolon (or end of string or closing angle bracket '>'). Placing a > semicolon in the user part will confuse them. > > > > > > Slightly kludgier but at least syntactically workable would be to > > > differently quote the meta characters in the tel:. > > > > or remove @ from the list of characters in headers and make it have to > > be escaped. > > > So we hack/simplify things by removing the @ character from headers so that > we can place the ; in the user part?? Doesn't sound like a good trade off to > me. > > > But it is not backwards compatible at all If an old parser sees %%3b > > then it will not correctly parse it anyway. I don't really > > like adding > > and removing characters from the BNF but I think it is preferable to > > adding a new escaping mechanism that will make things fuzzier and more > > complicated. > > Ok ok ... I knew I should have suggested an alternate quoting mechanism from > the outset. > The translation may make conversion of the telephone-subscriber ever so > slightly more complicated but at least the complication and changes are > localized to just this area (and not pushed to complicating the whole SIP > URL parsing). > > One of the simplest methods would be to translate the tel: reserved > characters ';' & '?' to two other URI reserved characters (RFC2396) that are > unreserved characters in the SIP user part. > > '&', '$' and '/' fulfill these conditions. > > So simply translate ; to & and ? to $. > > Something a little more idiot proof is to translate them to something > longer, eg: > ; to /%3b/ > ? to /%3f/ > > See any problems ? Got any objections or preference ? > > 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 Jul 6 01:21:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27820 for ; Thu, 6 Jul 2000 01:21:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E27E3443E6; Thu, 6 Jul 2000 01:21:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.idc1.level3.com (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 7B8B6443DE for ; Thu, 6 Jul 2000 01:21:23 -0400 (EDT) Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140]) by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id FAA28429; Thu, 6 Jul 2000 05:21:22 GMT From: Jon.Peterson@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id XAA01597; Wed, 5 Jul 2000 23:21:22 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jul 2000 23:23:03 -0600 Message-ID: <87A245E94948D3118DE30008C716B01301523A03@c0005v1idc1.oss.level3.com> To: jdrosen@dynamicsoft.com Cc: Gonzalo.Camarillo@lmf.ericsson.se, sip@lists.bell-labs.com Subject: RE: [SIP] QoS & Third Party Call Control in SIP Date: Wed, 5 Jul 2000 23:21:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have a question about the flow below. When C has acquired the provisional media (183) SDP from A, is that the time at which C would like to send an INVITE to B? Or would C rather wait until someone actually picks up the phone at A? Obviously, in a telephone-based service, if A has not yet answered when B starts ringing, this could lead to confusion, if the service is structured in such a way that the order of operations is important. I would have thought that C would wait until a user had answered at A (200 OK received) before sending an INVITE to B. In this case, the held SDP enables C to ACK the 200 OK and re-INVITE when it receives B's SDP. But again, it may depend on the service that one is implementing. Jon Peterson Level(3) Communications -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 05, 2000 10:45 PM To: Peterson, Jon Cc: Gonzalo.Camarillo@lmf.ericsson.se; sip@lists.bell-labs.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP Jon.Peterson@Level3.com wrote: > > My $.02: > > In the case of some services, it makes sense for C to send A a 'holding' SDP > (directing c= to 0.0.0.0) in the first INVITE rather than omitting SDP > entirely. Mostly, these are services for which it is likely that A will > perceive a long hiatus between the transmission of its 200 message to C and > the receipt of an ACK (I think C could want to wait until A picks up, 200 as > opposed to 18x, before ringing B, hence the possibility of a gap here). In many cases this holding approach makes sense. The new version of the 3pcc draft will contain a discussion of this issue. > > Now, of course, one could send a=qos preconditions in this holding SDP, but > obviously without B's SDP this will not enable A to send any resource > reservation signals. What it -does- allow is for C to send an immediate ACK > to A, and then re-INVITE A later with the qos preconditions and B's media > characteristics. This should be compatible with your flow below, in which B > has already reserved resources. Well, C can't send an ACK since there is no final response yet. It could include the update SDP in the PRACK, in which case you wouldn't need to do a re-INVITE. Its worth some discussion about whether PRACK can contain updated SDP; this sort of combines two very different functions into a single request (acknowledging a response and updating SDP). THen again, we've already combined those with normal ACK, so why not PRACK..? So, the call flow would look like: | INV (held SDP w/ preconditions) | | ----------------> | | | 183 SDP A | | | <---------------- | | | INV SDP A w/ preconditions | | ------------------+----------------> | | 183 SDP B | | | <-----------------+----------------- | | PRACK SDP B w/ preconditions | | ----------------->| | | PRACK | | | ------------------+----------------->| | 200 PRACK | | | <-----------------| | | | | | 200 PRACK | | |<------------------+------------------| | | | | COMET | | |<------------------| | | | | | COMET | | |<------------------+------------------| | | | | COMET | | |-----------------> | | | | | | COMET | | |-------------------+----------------->| | | | | | | | | | | | | | | | | | | | | | | | | | A C B Notice something very important here. The COMET need to be sent from the UAS back to the UAC. Thats because for the 3pcc case, C, which is the UAC for both INVITEs, does not have a way to know whether reservation was successful. I think the current manyfolks drafts says that the UAC only needs to send a COMET. We may need to rethink making this symmetric to support this 3pcc 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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 01:52:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01448 for ; Thu, 6 Jul 2000 01:52:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AFD1443EA; Thu, 6 Jul 2000 01:52:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D8F7344341 for ; Thu, 6 Jul 2000 01:52:02 -0400 (EDT) Received: from dynamicsoft.com (1Cust64.tnt1.freehold.nj.da.uu.net [63.17.113.64]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09291; Thu, 6 Jul 2000 01:49:34 -0400 (EDT) Message-ID: <39641E30.828620F4@dynamicsoft.com> Date: Thu, 06 Jul 2000 01:50:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: "Fairlie-Cuninghame, Robert" , "'Gethin Liddell'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: <396411CB.238DDBE@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Simple solution: any @ should be reserved (and thus needs to be escaped) > since it is syntactically significant in SIP URLs. (@ has no syntactic > significance in RFC 2806 and thus this transformation is harmless.) > Translating tel: URL delimiters into something else is really, really > ugly and just cascades the problem. I agree. I'd rather escape @ within parameters if present. I doubt there are any current uses for @ within parameters, but we do have uses for semicolons and other things in the user part, in order to support tel URL syntax, which is quite important. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 03: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 ESMTP id DAA08940 for ; Thu, 6 Jul 2000 03:08:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB7BA443AC; Thu, 6 Jul 2000 03:08:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 39BAC44341 for ; Thu, 6 Jul 2000 03:08:03 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e66781s19778; Thu, 6 Jul 2000 09:08:01 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA27361; Thu, 6 Jul 2000 10:08:00 +0300 (EET DST) Message-ID: <3964301C.41C35CEF@lmf.ericsson.se> Date: Thu, 06 Jul 2000 10:07:08 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jon.Peterson@Level3.com Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP References: <87A245E94948D3118DE30008C716B01301523A03@c0005v1idc1.oss.level> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Jon.Peterson@Level3.com wrote: > > I have a question about the flow below. When C has acquired the provisional > media (183) SDP from A, is that the time at which C would like to send an > INVITE to B? Or would C rather wait until someone actually picks up the > phone at A? The idea is to establish a session between A and B. The presence of C should be transparent to the user plane. So, C issues the INVITE without waiting for A to pick up the phone. In fact, A's phone is not ringing, since the preconditions are not met yet. Third party control is useful not just for "telephones". A might be, for instance, a SIP video camera and B a storage device. We do not want the storage device to begin recording until the camera begins filming (nor the other way around)... Jonathan Rosenberg wrote: > Well, C can't send an ACK since there is no final response yet. It could > include the update SDP in the PRACK, in which case you wouldn't need to > do a re-INVITE. I like better the PRACK solution than the re-INVITE approach. PARCKs would provide a way of updating SDPs from the UAC towards the UAS. In some situations this is very useful. 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 03:10:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08962 for ; Thu, 6 Jul 2000 03:10:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 99E07443EF; Thu, 6 Jul 2000 03:10:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id AA5A5443EC for ; Thu, 6 Jul 2000 03:10:03 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jul 2000 00:11:08 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , Henning Schulzrinne Cc: "'Gethin Liddell'" , sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Thu, 6 Jul 2000 00:11:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com If this is the route you want to take (allowing semicolons in the user part), you will definitely need to add this to the SIP Torture Tests. IMO this will be one of those things that will be often implemented incorrectly in lesser SIP parsers. This in itself limits the usefulness of telephone-subscriber for widespread interoperability. Personally, I'd rather do something a little esoteric (which requires some extra processing on telephone-subscriber capable systems) but be guaranteed that dumb SIP parsers won't have a problem with it. Obviously you can't keep the protocol restricted to the lowest implementations but in my mind it would be good if we could avoid this URL parsing complication somehow. Robert. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, July 06, 2000 1:51 PM > To: Henning Schulzrinne > Cc: Fairlie-Cuninghame, Robert; 'Gethin Liddell'; > sip@lists.bell-labs.com > Subject: Re: [SIP] SIP URL telephone-subscriber syntax. > > > > > Henning Schulzrinne wrote: > > > > Simple solution: any @ should be reserved (and thus needs > to be escaped) > > since it is syntactically significant in SIP URLs. (@ has > no syntactic > > significance in RFC 2806 and thus this transformation is harmless.) > > Translating tel: URL delimiters into something else is > really, really > > ugly and just cascades the problem. > > I agree. I'd rather escape @ within parameters if present. I > doubt there > are any current uses for @ within parameters, but we do have uses for > semicolons and other things in the user part, in order to support tel > URL syntax, which is quite important. > > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 05:19:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09969 for ; Thu, 6 Jul 2000 05:19:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D1E7443E5; Thu, 6 Jul 2000 05:18:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by lists.bell-labs.com (Postfix) with ESMTP id 7F28D44341 for ; Thu, 6 Jul 2000 05:18:40 -0400 (EDT) Received: from pqm-cons.demon.co.uk ([158.152.93.237] helo=P162U) by finch-post-10.mail.demon.net with smtp (Exim 2.12 #1) id 13A7nr-000BrT-0A; Thu, 6 Jul 2000 09:18:39 +0000 From: "Alex Hardisty" To: "Jonathan Rosenberg" , "Jo Hornsby" Cc: "Krishna G" , Subject: RE: [SIP] on directed pick up service Date: Thu, 6 Jul 2000 10:20:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <39640839.73912D4D@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > The service definition is whatever you want it to be. We here at IETF > don't specify services, but rather protocols to support services. But don't you have to know what the service is and how it behaves before you can define the protocol to support it? Or at least, have some specification of the characteristics of the group of services for which you want to define a general protocol? To me this lack of service descriptions appears to be a weakness of the IETF approach. If I buy SIP phones from one vendor, a SIP PBX from another vendor and a SIP based voicemail server from somewhere else, how can I be sure of interoperability between them? How can I be sure they will handle, for example, call transfer, call forwarding, and message waiting in a consistent manner? What happens as the services start to become more complex, perhaps involving many different server types? Services in the mobility area (both terminal and personal mobility) typically involve upto 8 different functional entities with many detailed information flows between them. If there is no specification for how the service should work, how will a major corporation establish a Worldwide service to provide corporate mobility with equipment sourced from several vendors? -- Alex Hardisty PQM Consultants _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 05:26:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10017 for ; Thu, 6 Jul 2000 05:26:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C18BB443B0; Thu, 6 Jul 2000 05:26:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 4EE9244373 for ; Thu, 6 Jul 2000 05:26:37 -0400 (EDT) Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA07409; Thu, 6 Jul 2000 10:24:35 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Fairlie-Cuninghame, Robert" , Henning Schulzrinne Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Thu, 6 Jul 2000 10:03:03 +0100 X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: sip@lists.bell-labs.com References: In-Reply-To: MIME-Version: 1.0 Message-Id: <0007061018350J.27308@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit On Thu, 06 Jul 2000, Fairlie-Cuninghame, Robert wrote: > Gethin, > > > > @ is not allowed in parameters. Therefore it would be possible to > > delimit the userinfo first by looking for @ and then parsing the host > > afterwards so in the case above (assuming the ; and ? hasve been added > > to the user bnf), this can only be resolved as ooops > From RFC2543bis (July 2000) the @ is a valid SIP parameter value (see my appologies, you are correct. i mis-read the bis and thought for some reason that @ was an invalid parameter char :( However, my opinion is still that it will be easier to make @ a reserved character for both parameters and headers than it would to change the whole escaping mechanism that is currently in use. I do see problems with the new method you suggested. For example, the suggested characters & and $ are valid in their own right in the tel url (unless i've read it wrong again :) ) so we would need to translate or do something with all occurances of them. The same problem occurs with `/' being used in the longer escaped string. -- 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 Jul 6 05:42:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10171 for ; Thu, 6 Jul 2000 05:42:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7FCC7443D0; Thu, 6 Jul 2000 05:41:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id B6C0A44341 for ; Thu, 6 Jul 2000 05:41:39 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e669fcs03916; Thu, 6 Jul 2000 11:41:38 +0200 (MET DST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA06846; Thu, 6 Jul 2000 12:41:37 +0300 (EET DST) Message-ID: <3964541C.C653AB11@lmf.ericsson.se> Date: Thu, 06 Jul 2000 12:40:44 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Jon.Peterson@Level3.com, sip@lists.bell-labs.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP References: <87A245E94948D3118DE30008C716B01301523A02@c0005v1idc1.oss.level3.com> <39640EC8.AC5B8D72@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Jonathan Rosenberg wrote: > > Jon.Peterson@Level3.com wrote: > > > > My $.02: > > > > In the case of some services, it makes sense for C to send A a 'holding' SDP > > (directing c= to 0.0.0.0) in the first INVITE rather than omitting SDP > > entirely. Mostly, these are services for which it is likely that A will > > perceive a long hiatus between the transmission of its 200 message to C and > > the receipt of an ACK (I think C could want to wait until A picks up, 200 as > > opposed to 18x, before ringing B, hence the possibility of a gap here). > > In many cases this holding approach makes sense. The new version of the > 3pcc draft will contain a discussion of this issue. It has to be taken into account that we do not have information about port numbers nor codecs to be used. So, the m line defining the media stream will not contain codec or port information. Gonzalo > > > > Now, of course, one could send a=qos preconditions in this holding SDP, but > > obviously without B's SDP this will not enable A to send any resource > > reservation signals. What it -does- allow is for C to send an immediate ACK > > to A, and then re-INVITE A later with the qos preconditions and B's media > > characteristics. This should be compatible with your flow below, in which B > > has already reserved resources. > > Well, C can't send an ACK since there is no final response yet. It could > include the update SDP in the PRACK, in which case you wouldn't need to > do a re-INVITE. Its worth some discussion about whether PRACK can > contain updated SDP; this sort of combines two very different functions > into a single request (acknowledging a response and updating SDP). THen > again, we've already combined those with normal ACK, so why not PRACK..? > > So, the call flow would look like: > > | INV (held SDP w/ preconditions) | > | ----------------> | | > | 183 SDP A | | > | <---------------- | | > | INV SDP A w/ preconditions | > | ------------------+----------------> | > | 183 SDP B | | > | <-----------------+----------------- | > | PRACK SDP B w/ preconditions | > | ----------------->| | > | PRACK | | > | ------------------+----------------->| > | 200 PRACK | | > | <-----------------| | > | | | > | 200 PRACK | | > |<------------------+------------------| > | | | > | COMET | | > |<------------------| | > | | | > | COMET | | > |<------------------+------------------| > | | | > | COMET | | > |-----------------> | | > | | | > | COMET | | > |-------------------+----------------->| > | | | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > | > A > C B > > Notice something very important here. The COMET need to be sent from the > UAS back to the UAC. Thats because for the 3pcc case, C, which is the > UAC for both INVITEs, does not have a way to know whether reservation > was successful. I think the current manyfolks drafts says that the UAC > only needs to send a COMET. We may need to rethink making this symmetric > to support this 3pcc 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: (732) 741-7244 > http://www.dynamicsoft.com -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 07:28:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12197 for ; Thu, 6 Jul 2000 07:28:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 503DC44390; Thu, 6 Jul 2000 07:28:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by lists.bell-labs.com (Postfix) with ESMTP id 37AEE44336 for ; Thu, 6 Jul 2000 07:28:15 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id HAA02814; Thu, 6 Jul 2000 07:27:05 -0400 (EDT) Date: Thu, 6 Jul 2000 07:27:05 -0400 (EDT) From: Scott Bradner Message-Id: <200007061127.HAA02814@newdev.harvard.edu> To: alex.hardisty@pqmconsultants.com, jdrosen@dynamicsoft.com, jhornsby@ubiquity.net Subject: RE: [SIP] on directed pick up service Cc: gundama@sasi.com, sip@lists.bell-labs.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > But don't you have to know what the service is and how it behaves before you > can define the protocol to support it? I would hope that we are not so limited that we define protocols that only support the services we can agree to today - the Internet would not be what it is if that was the way that IP had been defined Scott _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 09:55:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16611 for ; Thu, 6 Jul 2000 09:55:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE8E3443AE; Thu, 6 Jul 2000 09:55:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 7C47A44390 for ; Thu, 6 Jul 2000 09:55:35 -0400 (EDT) Received: (qmail 4842 invoked by uid 1002); 6 Jul 2000 13:54:41 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Jul 2000 16:54:39 +0300 (IDT) To: SIP X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14692.36246.833746.322929@jodie.lucid> Subject: [SIP] Proxying ACKs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Section 4.2.2 says that if a proxy receives a final non-success reply, it should try and figure out whether it should proxy it or not. However, the RFC also says that for each final non-success reply, the first proxy should ACK it. I can't seem to understand under what condition should a proxy proxy an ACK request. I can't think of any situation where an ACK needs to be proxied for final non-success replies, since the ACK is always sent hop-by-hop, and not end-to-end. This brings me to another question. The RFC says that a proxy should proxy the following ACKs: 1. If it cannot find a call-leg that corresponds to this ACK. 2. If it never sent any replies. I don't understand why a proxy should proxy ACKs, if it cannot find a call-leg, or if it seems like its state does not correspond to receiving an ACK now. If my proxy also handles QoS, or handles billing, or any other type of situation where it will need to maintain call states, then I don't see why it should allow such wandering ACKs to travel through it. Allowing these ACKs will change the state of the proxy, not in the proper way. Can anybody clarify this to me? -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 10:16:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16906 for ; Thu, 6 Jul 2000 10:16:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 00B8B443D8; Thu, 6 Jul 2000 10:15:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 7002C44338 for ; Thu, 6 Jul 2000 10:15:49 -0400 (EDT) Received: (qmail 4857 invoked by uid 1002); 6 Jul 2000 14:14:56 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Jul 2000 17:14:56 +0300 (IDT) To: SIP X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14692.37869.251930.807568@jodie.lucid> Subject: [SIP] OK with no ACK Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think that a situation where the calle sent OK, but doesn't receive ACK for an extended period of time should be handled. I'm implementing a timeout on OK replies, that will kill the call if no ACK was received after a defined period of time. My question is, should I send a CANCEL or a BYE? -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 10:22:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16984 for ; Thu, 6 Jul 2000 10:22:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 007C7443EF; Thu, 6 Jul 2000 10:21:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 9C472443DB for ; Thu, 6 Jul 2000 10:21:08 -0400 (EDT) Received: (qmail 4863 invoked by uid 1002); 6 Jul 2000 14:20:15 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Jul 2000 17:20:15 +0300 (IDT) To: SIP X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14692.38251.470161.860230@jodie.lucid> Subject: [SIP] Port in Request-URI Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I'm not clear whether a Request-URI can or cannot have a port number. Although I saw somewhere in the RFC that a Request-URI can have a port, I see no examples of such use. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 10:28:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17137 for ; Thu, 6 Jul 2000 10:28:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A75E443F3; Thu, 6 Jul 2000 10:27:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ort-exch.outreachtech.com (unknown [208.246.106.18]) by lists.bell-labs.com (Postfix) with ESMTP id CE8A9443DB for ; Thu, 6 Jul 2000 10:27:27 -0400 (EDT) Received: by ORT-EXCH with Internet Mail Service (5.5.2650.21) id <3K8C0JCN>; Thu, 6 Jul 2000 10:27:13 -0400 Message-ID: <91522176F94CD4119FAB00B0D0492B4312AC85@ORT-EXCH> From: "Vakil, Mohammad" To: "'Dvir Oren'" , SIP Subject: RE: [SIP] OK with no ACK Date: Thu, 6 Jul 2000 10:27:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com You don't send a CANCEL or BYE if don't receive any ACK to your 200 OK. You can just kill the call after retransmission timer runs out. But you MUST keep retransmitting 200 OK until timer runs out. Mohammad Vakil OutReach Technologies -----Original Message----- From: Dvir Oren [mailto:dvir@lucidvon.com] Sent: Thursday, July 06, 2000 10:15 AM To: SIP Subject: [SIP] OK with no ACK I think that a situation where the calle sent OK, but doesn't receive ACK for an extended period of time should be handled. I'm implementing a timeout on OK replies, that will kill the call if no ACK was received after a defined period of time. My question is, should I send a CANCEL or a BYE? -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 10:33:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17232 for ; Thu, 6 Jul 2000 10:33:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4C7B3443EC; Thu, 6 Jul 2000 10:32:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 614B4443BC for ; Thu, 6 Jul 2000 10:32:05 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA07618; Thu, 6 Jul 2000 15:29:28 +0100 (BST) From: "Jo Hornsby" To: "Dvir Oren" , "SIP" Subject: RE: [SIP] Proxying ACKs Date: Thu, 6 Jul 2000 15:29:28 +0100 Message-ID: <002201bfe756$97b92440$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: <14692.36246.833746.322929@jodie.lucid> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Section 4.2.2 says that if a proxy receives a final non-success reply, > it should try and figure out whether it should proxy it or not. Not quite. It says that if it had _sent_ a definitive, non-2xx, then it should try and figure out whether it should proxy the ACK or not. > However, the RFC also says that for each final non-success reply, the > first proxy should ACK it. Yes, that's correct. > I can't seem to understand under what > condition should a proxy proxy an ACK request. I can't think of any > situation where an ACK needs to be proxied for final non-success > replies, since the ACK is always sent hop-by-hop, and not end-to-end. In general, it's probably not going to be a frequent occurrence. It's going to occur when a 200 response arrives very late; that is, after the proxy had decided that the transaction was completed (because all branches had completed or timed-out or whatever); and the requesting UAC routes the ACK back through the proxy (because of Record-Route: or missing Contact: or whatever). I'm trying to think if it can happen if a downstream proxy transitions from stateful to stateless "early". I don't think it can if the proxy in question here still has state on the transaction (I question this because of the indented rationale in 4.2.2 -- I'm not quite clear on why it's there). (There are also other cases where the INVITE already contained a tag in the To header; these are dealt with by section 12.3.5.) > This brings me to another question. The RFC says that a proxy should > proxy the following ACKs: > 1. If it cannot find a call-leg that corresponds to this ACK. > 2. If it never sent any replies. > > I don't understand why a proxy should proxy ACKs, if it cannot find a > call-leg, or if it seems like its state does not correspond to > receiving an ACK now. I'm not quite following what you mean by state, here. A proxy should probably not rely on ACKs to maintain any sort of transaction state, since it's not guaranteed to ever see the ACK. If you're talking about call-state, I'm not sure that the proxy should start mandating that UAs are in the same state that it thinks they should be in (but of course, there's doubtless going to be billing applications and whathaveyou where such decisions will be required). In the case I talked about above (the late 200), an ACK could conceivably arrive after the proxy had dropped all state on the INVITE. If the proxy did not try and route in this case, the call would never properly be set up from the receiving UAS's point-of-view. I think there's other nasty conditions, such as non-complete Route headers; probably most of them tend to indicate buggy implementations somewhere along the path. > If my proxy also handles QoS, or handles billing, or any other type of > situation where it will need to maintain call states, then I don't see > why it should allow such wandering ACKs to travel through it. > Allowing these ACKs will change the state of the proxy, not in the > proper way. Yes, well here is where you potentially get problems. Once you get into issues where there's money involved, if you pay the Proxy enough, doubtless it'll be willing to "lose" the ACKs for you... &:) HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 10:37:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17338 for ; Thu, 6 Jul 2000 10:37:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12E4344409; Thu, 6 Jul 2000 10:34:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 63E5E44406 for ; Thu, 6 Jul 2000 10:34:54 -0400 (EDT) Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA08664; Thu, 6 Jul 2000 07:34:12 -0700 (PDT) Date: Thu, 6 Jul 2000 10:33:46 -0400 (EDT) From: Mark Eastman To: schulzrinne@cs.columbia.edu Cc: rfairlie@nuera.com, gethin@ubiquity.net, sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hello, I saw part of a thread of your discussion on TEL URLs shown below. I was wondering what the initial question was. Does this discussion involve tel: URLs being transformed to sip: URLs or handling tel: separately? (i.e. tel:5555555 = sip:555555@host.com;user=phone). Thanks, Mark --------------------------------------------------- Simple solution: any @ should be reserved (and thus needs to be escaped) since it is syntactically significant in SIP URLs. (@ has no syntactic significance in RFC 2806 and thus this transformation is harmless.) Translating tel: URL delimiters into something else is really, really ugly and just cascades the problem. "Fairlie-Cuninghame, Robert" wrote: > > Gethin, > > > > @ is not allowed in parameters. Therefore it would be possible to > > delimit the userinfo first by looking for @ and then parsing the host > > afterwards so in the case above (assuming the ; and ? hasve been added > > to the user bnf), this can only be resolved as > > > > user = ABCD;dog=cat > > host = fish.com > > > > > I think you misinterpreted my example (the parameter cat=dog originated as a > tel: prameter not a sip one; however it may be interpreted as a SIP > parameter dog=cat@fish.com - that's the ambiguity). > > sip:ABCD;dog=cat@fish.com;user=phone > > >From RFC2543bis (July 2000) the @ is a valid SIP parameter value (see > below). So if the parser doesn't understand the user=phone parameter (or is > not very careful in handling the tel:) then it WILL be misinterpreted!!! See > what I mean about this making the SIP URL parsing complicated and > conditional on the understanding of a parameter value !!! > > other-param = pname - pname "=" pvalue (Henning, I assume that is supposed > to be a '|' not a hyphen in the document, right ?). > pname = 1 * paramchar > pvalue = 1 * paramchar > paramchar = param-unreserved | unreserved | escaped > param-unreserved = [ | ] | / | : | @ | & | + | $ > > > > If the parser determines the end of the user@host:port by > > searching for a > > > semicolon then the same thing will occur. This is a valid > > (as far as I can > > > see) and simple way for parser to pull out the base URL (until now). > > > > do you mean searching for a question mark here? If you do > > then i agree > > this is a problem. Slightly modifying your example (whether > > there is a > > user parameter or not does not matter): > > > > No. I am simply anticipating how some parsers might currently work. > > sip:user@host:port;option1=optionval;etc=etcval > > An easy way to retrieve the user@host:port section is to search for the > first semicolon (or end of string or closing angle bracket '>'). Placing a > semicolon in the user part will confuse them. > > > > > > Slightly kludgier but at least syntactically workable would be to > > > differently quote the meta characters in the tel:. > > > > or remove @ from the list of characters in headers and make it have to > > be escaped. > > > So we hack/simplify things by removing the @ character from headers so that > we can place the ; in the user part?? Doesn't sound like a good trade off to > me. > > > But it is not backwards compatible at all If an old parser sees %%3b > > then it will not correctly parse it anyway. I don't really > > like adding > > and removing characters from the BNF but I think it is preferable to > > adding a new escaping mechanism that will make things fuzzier and more > > complicated. > > Ok ok ... I knew I should have suggested an alternate quoting mechanism from > the outset. > The translation may make conversion of the telephone-subscriber ever so > slightly more complicated but at least the complication and changes are > localized to just this area (and not pushed to complicating the whole SIP > URL parsing). > > One of the simplest methods would be to translate the tel: reserved > characters ';' & '?' to two other URI reserved characters (RFC2396) that are > unreserved characters in the SIP user part. > > '&', '$' and '/' fulfill these conditions. > > So simply translate ; to & and ? to $. > > > Something a little more idiot proof is to translate them to something > longer, eg: > ; to /%3b/ > ? to /%3f/ > > See any problems ? Got any objections or preference ? > > 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 Jul 6 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 ESMTP id KAA17479 for ; Thu, 6 Jul 2000 10:42:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1AF944414; Thu, 6 Jul 2000 10:38:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ort-exch.outreachtech.com (unknown [208.246.106.18]) by lists.bell-labs.com (Postfix) with ESMTP id E540F4440D for ; Thu, 6 Jul 2000 10:38:49 -0400 (EDT) Received: by ORT-EXCH with Internet Mail Service (5.5.2650.21) id <3K8C0JDB>; Thu, 6 Jul 2000 10:38:30 -0400 Message-ID: <91522176F94CD4119FAB00B0D0492B4312AC86@ORT-EXCH> From: "Vakil, Mohammad" To: "'Dvir Oren'" , SIP Subject: RE: [SIP] Port in Request-URI Date: Thu, 6 Jul 2000 10:38:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Yes, Request-URI can have a port number. In fact, whenever port number is other than 5060, it must be there. That's how proxy will forward the request based on the domain in Request-URI. Mohammad Vakil OutReach Technologies -----Original Message----- From: Dvir Oren [mailto:dvir@lucidvon.com] Sent: Thursday, July 06, 2000 10:20 AM To: SIP Subject: [SIP] Port in Request-URI I'm not clear whether a Request-URI can or cannot have a port number. Although I saw somewhere in the RFC that a Request-URI can have a port, I see no examples of such use. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 10:49:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17600 for ; Thu, 6 Jul 2000 10:49:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C7DD7443DB; Thu, 6 Jul 2000 10:48:05 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id B383D4433E for ; Thu, 6 Jul 2000 10:48:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jul 6 10:46:09 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 70FFF44354; Thu, 6 Jul 2000 10:33:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 0F11944347 for ; Thu, 6 Jul 2000 10:33:00 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA28583; Thu, 6 Jul 2000 09:32:57 -0500 Cc: SIP Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA28570; Thu, 6 Jul 2000 09:32:54 -0500 Message-ID: <39649894.BF91AFA@lucent.com> Date: Thu, 06 Jul 2000 09:32:52 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Original-CC: SIP Subject: Re: [SIP] OK with no ACK References: <14692.37869.251930.807568@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir Oren wrote: > > I think that a situation where the calle sent OK, but doesn't receive > ACK for an extended period of time should be handled. I'm > implementing a timeout on OK replies, that will kill the call if no > ACK was received after a defined period of time. > > My question is, should I send a CANCEL or a BYE? I would send a CANCEL since the call has not been established until the ACK from the caller gets to the callee. That is the behavior of my proxy. A BYE (to me at least) conveys that a session was successfully established and is now being torn down. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 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 Jul 6 10:55:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17695 for ; Thu, 6 Jul 2000 10:55:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DA484440A; Thu, 6 Jul 2000 10:54:07 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 7E01C4433E for ; Thu, 6 Jul 2000 10:54:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu Jul 6 10:53:33 EDT 2000 Received: by lists.bell-labs.com (Postfix) id EC76544355; Thu, 6 Jul 2000 10:39:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 9F9EC44347 for ; Thu, 6 Jul 2000 10:39:01 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA01165; Thu, 6 Jul 2000 09:38:58 -0500 Cc: SIP Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA01152; Thu, 6 Jul 2000 09:38:56 -0500 Message-ID: <396499FE.1C611CBE@lucent.com> Date: Thu, 06 Jul 2000 09:38:54 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Original-CC: SIP Subject: Re: [SIP] Port in Request-URI References: <14692.38251.470161.860230@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir Oren wrote: > > I'm not clear whether a Request-URI can or cannot have a port number. > Although I saw somewhere in the RFC that a Request-URI can have a > port, I see no examples of such use. A Request-URI is a SIP URL as described in Section 2 of the bis draft. SIP URLs include hostport as a mandatory element where hostport = host [":" port] Thus a Request-URI MAY contain a port number. A Request-URI of the form sip:vkg@darknight.ih.lucent.com:5065 is perfectly valid and my SIP UAC can put this in my From: or Contact: headers when sending a request. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 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 Jul 6 11:00:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17807 for ; Thu, 6 Jul 2000 11:00:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D436E44417; Thu, 6 Jul 2000 10:57:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ort-exch.outreachtech.com (unknown [208.246.106.18]) by lists.bell-labs.com (Postfix) with ESMTP id 1CC1F4433E for ; Thu, 6 Jul 2000 10:57:53 -0400 (EDT) Received: by ORT-EXCH with Internet Mail Service (5.5.2650.21) id <3K8C0JD7>; Thu, 6 Jul 2000 10:57:38 -0400 Message-ID: <91522176F94CD4119FAB00B0D0492B4312AC87@ORT-EXCH> From: "Vakil, Mohammad" To: "'vkg@lucent.com'" , Dvir Oren Cc: SIP Subject: RE: [SIP] OK with no ACK Date: Thu, 6 Jul 2000 10:57:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Vijay - How can a User Agent Server issue a Cancel? What Dvir is describing here is a UAS is trying to send 200 OK and never receives an ACK. It should just kill the call without having to send anything after retransmission time out. Mohammad Vakil OutReach Technologies -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@lucent.com] Sent: Thursday, July 06, 2000 10:33 AM To: Dvir Oren Cc: SIP Subject: Re: [SIP] OK with no ACK Dvir Oren wrote: > > I think that a situation where the calle sent OK, but doesn't receive > ACK for an extended period of time should be handled. I'm > implementing a timeout on OK replies, that will kill the call if no > ACK was received after a defined period of time. > > My question is, should I send a CANCEL or a BYE? I would send a CANCEL since the call has not been established until the ACK from the caller gets to the callee. That is the behavior of my proxy. A BYE (to me at least) conveys that a session was successfully established and is now being torn down. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 11:17:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18253 for ; Thu, 6 Jul 2000 11:17:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DA2844419; Thu, 6 Jul 2000 11:16:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0436E443FA for ; Thu, 6 Jul 2000 11:16:18 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA11205; Thu, 6 Jul 2000 11:17:36 -0400 (EDT) Message-ID: <3964A355.4535A9C7@dynamicsoft.com> Date: Thu, 06 Jul 2000 11:18:45 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vakil, Mohammad" Cc: "'vkg@lucent.com'" , Dvir Oren , SIP Subject: Re: [SIP] OK with no ACK References: <91522176F94CD4119FAB00B0D0492B4312AC87@ORT-EXCH> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think Vijay is saying that his proxy sends a CANCEL if it doesn't see the ACK before the timeout fires. Note that this will not do anything useful, since the final response has already been sent by the UAS. CANCEL requests a UAS to send a 487 to the original request if the original request has not been responded to. In this case, it has been responded to, with a 200 OK. So, CANCEL has no effect. Mohammed is also correct that the UAS never sends a CANCEL for a request it receives. THe proper behavior here is for the UAS to consider the call disconnected if it does not receive ACK even after having sent the 7 (or whatever it is) 200 OK responses. This does mean that the UAC will believe the call up, and the UA believe it down. You might think responding to ACK might have helped this problem, but it doesn't. Its the classic byzantine armies (or is it byzantine generals?) problem in network protocols. The state inconsistency only arises in catastrophic network failures; things like session timer will quickly discover these things and result in BYE. Having the called party send BYE might not help either. Thats because the failure could be because the 200 OKs are all getting lost (in which case the BYE doesn't help), or the ACKs getting lost (in which case the BYE would help). -Jonathan R. "Vakil, Mohammad" wrote: > > Vijay - > > How can a User Agent Server issue a Cancel? What Dvir is describing here is > a UAS is trying to send 200 OK and never receives an ACK. It should just > kill the call without having to send anything after retransmission time out. > > Mohammad Vakil > OutReach Technologies > > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Thursday, July 06, 2000 10:33 AM > To: Dvir Oren > Cc: SIP > Subject: Re: [SIP] OK with no ACK > > Dvir Oren wrote: > > > > I think that a situation where the calle sent OK, but doesn't receive > > ACK for an extended period of time should be handled. I'm > > implementing a timeout on OK replies, that will kill the call if no > > ACK was received after a defined period of time. > > > > My question is, should I send a CANCEL or a BYE? > > I would send a CANCEL since the call has not been established until the > ACK from the caller gets to the callee. That is the behavior of my > proxy. A BYE (to me at least) conveys that a session was successfully > established and is now being torn down. > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org > IN Architecture and Internet Software Group > Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 11:21:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18327 for ; Thu, 6 Jul 2000 11:21:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9443A4441D; Thu, 6 Jul 2000 11:20:06 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id E4AD044338 for ; Thu, 6 Jul 2000 11:20:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jul 6 11:19:40 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 146CB44354; Thu, 6 Jul 2000 11:06:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id B4D2A44347 for ; Thu, 6 Jul 2000 11:06:30 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA13434; Thu, 6 Jul 2000 10:06:27 -0500 Cc: Dvir Oren , SIP Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA13366; Thu, 6 Jul 2000 10:06:24 -0500 Message-ID: <3964A06E.3DE6A800@lucent.com> Date: Thu, 06 Jul 2000 10:06:22 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vakil, Mohammad" Original-CC: Dvir Oren , SIP Subject: Re: [SIP] OK with no ACK References: <91522176F94CD4119FAB00B0D0492B4312AC87@ORT-EXCH> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Vakil, Mohammad" wrote: > > Vijay - > > How can a User Agent Server issue a Cancel? What Dvir is describing > here is a UAS is trying to send 200 OK and never receives an ACK. It > should just kill the call without having to send anything after > retransmission time out. Mohammad: You are correct; I mistook Dvir's scenario for another context that I have been thinking about recently (when you have a hammer, everything looks like a nail...). Clearly, in case of an INVITE if the caller does not receive an ACK to the 200 OK, it will keep on re-transmitting the 200 OK until it has exhausted its retry limit. Sorry for the confusion - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 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 Jul 6 11:23:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18444 for ; Thu, 6 Jul 2000 11:23:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB54A44422; Thu, 6 Jul 2000 11:21:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ort-exch.outreachtech.com (unknown [208.246.106.18]) by lists.bell-labs.com (Postfix) with ESMTP id 9951644420 for ; Thu, 6 Jul 2000 11:21:27 -0400 (EDT) Received: by ORT-EXCH with Internet Mail Service (5.5.2650.21) id <3K8C0J10>; Thu, 6 Jul 2000 11:21:03 -0400 Message-ID: <91522176F94CD4119FAB00B0D0492B4312AC88@ORT-EXCH> From: "Vakil, Mohammad" To: "'Agboh, Charles'" , "Vakil, Mohammad" Cc: "'sip'" Subject: RE: [SIP] OK with no ACK Date: Thu, 6 Jul 2000 11:21:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Charles - You cannot issue BYE whenever you want. Section 4.2.3 in the bis draft says: "A BYE request from either called or calling party terminates any pending INVITE, but the INVITE request transaction MUST be completed with a final response." Mohammad Vakil OutReach Technologies -----Original Message----- From: Agboh, Charles [mailto:Charles.Agboh@gtsgroup.com] Sent: Thursday, July 06, 2000 11:10 AM To: 'Vakil, Mohammad' Subject: RE: [SIP] OK with no ACK The CANCEL doesn't apply to the calle since it never issued a request for that session. Right? AS a callee, I can issue a BYE when ever I want right (after receiving an invite af course)? -----Original Message----- From: Vakil, Mohammad [mailto:MVakil@outreachtech.com] Sent: Thursday, July 06, 2000 4:58 PM To: 'vkg@lucent.com'; Dvir Oren Cc: SIP Subject: RE: [SIP] OK with no ACK Vijay - How can a User Agent Server issue a Cancel? What Dvir is describing here is a UAS is trying to send 200 OK and never receives an ACK. It should just kill the call without having to send anything after retransmission time out. Mohammad Vakil OutReach Technologies -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@lucent.com] Sent: Thursday, July 06, 2000 10:33 AM To: Dvir Oren Cc: SIP Subject: Re: [SIP] OK with no ACK Dvir Oren wrote: > > I think that a situation where the calle sent OK, but doesn't receive > ACK for an extended period of time should be handled. I'm > implementing a timeout on OK replies, that will kill the call if no > ACK was received after a defined period of time. > > My question is, should I send a CANCEL or a BYE? I would send a CANCEL since the call has not been established until the ACK from the caller gets to the callee. That is the behavior of my proxy. A BYE (to me at least) conveys that a session was successfully established and is now being torn down. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 11:25:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18475 for ; Thu, 6 Jul 2000 11:25:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB2544442A; Thu, 6 Jul 2000 11:23:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bruatvpnt01 (smtp1.gtsgroup.com [195.158.230.16]) by lists.bell-labs.com (Postfix) with SMTP id E21434441F for ; Thu, 6 Jul 2000 11:23:50 -0400 (EDT) Received: by brubhdpnt01.herten.com with Internet Mail Service (5.5.2650.21) id <3M24HZ7W>; Thu, 6 Jul 2000 17:22:18 +0200 Message-ID: From: "Agboh, Charles" To: "'vkg@lucent.com'" , "Vakil, Mohammad" Cc: Dvir Oren , SIP Subject: RE: [SIP] OK with no ACK Date: Thu, 6 Jul 2000 17:21:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Callers don't receive ACKs unless they received an invite from the callee. -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@lucent.com] Sent: Thursday, July 06, 2000 5:06 PM To: Vakil, Mohammad Cc: Dvir Oren; SIP Subject: Re: [SIP] OK with no ACK "Vakil, Mohammad" wrote: > > Vijay - > > How can a User Agent Server issue a Cancel? What Dvir is describing > here is a UAS is trying to send 200 OK and never receives an ACK. It > should just kill the call without having to send anything after > retransmission time out. Mohammad: You are correct; I mistook Dvir's scenario for another context that I have been thinking about recently (when you have a hammer, everything looks like a nail...). Clearly, in case of an INVITE if the caller does not receive an ACK to the 200 OK, it will keep on re-transmitting the 200 OK until it has exhausted its retry limit. Sorry for the confusion - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 11:26:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18499 for ; Thu, 6 Jul 2000 11:26:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06E2F44431; Thu, 6 Jul 2000 11:25:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C3D4044425 for ; Thu, 6 Jul 2000 11:25:28 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA11346; Thu, 6 Jul 2000 11:26:52 -0400 (EDT) Message-ID: <3964A581.5926D525@dynamicsoft.com> Date: Thu, 06 Jul 2000 11:28:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vakil, Mohammad" Cc: "'Dvir Oren'" , SIP Subject: Re: [SIP] Port in Request-URI References: <91522176F94CD4119FAB00B0D0492B4312AC86@ORT-EXCH> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit It can have a port number. But, let me explain when this is needed and when its not. Lets say I send a request to joe@example.com, and the server for example.com is listening on 5061. The request URI might look like: INVITE sip:joe@example.com:5061 SIP/2.0 this arrives at example.com. Since the request is for that server, it looks up joe in some database and translates the request URI (for example, to sip:joe@engineering.example.com). It looks up engineering.example.com in DNS, and finds an A record for that machine, forwarding the request to the given IP address. The outgoing request URI looks like: INVITE sip:joe@engineering.example.com SIP/2.0 Note that in this case, the presence of port 5061 in the request URI sent to example.com didn't make a difference. Thats because the example.com just translated the request URI. Whether it had contained the port number or not would have had no effect on processing. However, had the request instead been sent to a local outbound proxy instead of example.com, the port number would NEED to be there. Thats because the local outbound proxy won't translate the request URI, it will example it, determine its not for itself, look up the domain in the request URI in DNS, and forward the request there. So, the request URI needs to contain this port so that the local outbound proxy knows to forward it to 5061 as opposed to 5060 at example.com. So, the rule of thumb is this: if you send a request to the server listed in the domain of the request URI, URI parameters like port, transport, ttl etc MAY be present but are not needed. If you send a request to a server which is NOT the one identified in the request URI, you MUST include these parameters if they are not the defaults. Always inclduing them, when not default, means you don't need to determine which is the case, and is always the safest bet. -Jonathan R. "Vakil, Mohammad" wrote: > > Yes, Request-URI can have a port number. In fact, whenever port number is > other than 5060, it must be there. That's how proxy will forward the request > based on the domain in Request-URI. > > Mohammad Vakil > OutReach Technologies > > -----Original Message----- > From: Dvir Oren [mailto:dvir@lucidvon.com] > Sent: Thursday, July 06, 2000 10:20 AM > To: SIP > Subject: [SIP] Port in Request-URI > > I'm not clear whether a Request-URI can or cannot have a port number. > Although I saw somewhere in the RFC that a Request-URI can have a > port, I see no examples of such use. > > -- > Dvir Oren > Lucid VON Ltd. > 9 Saloniki St., Tel-Aviv Israel > Tel: +972 3 644 3038 Fax: +972 3 644 3039 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 11:29:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18576 for ; Thu, 6 Jul 2000 11:29:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1930544438; Thu, 6 Jul 2000 11:25:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bruatvpnt01 (smtp1.gtsgroup.com [195.158.230.16]) by lists.bell-labs.com (Postfix) with SMTP id 9CB0544425 for ; Thu, 6 Jul 2000 11:25:46 -0400 (EDT) Received: by brubhdpnt01.herten.com with Internet Mail Service (5.5.2650.21) id <3M24HZ0D>; Thu, 6 Jul 2000 17:24:26 +0200 Message-ID: From: "Agboh, Charles" To: "'Vakil, Mohammad'" Cc: "'sip'" Subject: RE: [SIP] OK with no ACK Date: Thu, 6 Jul 2000 17:23:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I thought the callee already issues the final response and is waiting for the ACK! -----Original Message----- From: Vakil, Mohammad [mailto:MVakil@outreachtech.com] Sent: Thursday, July 06, 2000 5:21 PM To: Agboh, Charles; Vakil, Mohammad Cc: 'sip' Subject: RE: [SIP] OK with no ACK Charles - You cannot issue BYE whenever you want. Section 4.2.3 in the bis draft says: "A BYE request from either called or calling party terminates any pending INVITE, but the INVITE request transaction MUST be completed with a final response." Mohammad Vakil OutReach Technologies -----Original Message----- From: Agboh, Charles [mailto:Charles.Agboh@gtsgroup.com] Sent: Thursday, July 06, 2000 11:10 AM To: 'Vakil, Mohammad' Subject: RE: [SIP] OK with no ACK The CANCEL doesn't apply to the calle since it never issued a request for that session. Right? AS a callee, I can issue a BYE when ever I want right (after receiving an invite af course)? -----Original Message----- From: Vakil, Mohammad [mailto:MVakil@outreachtech.com] Sent: Thursday, July 06, 2000 4:58 PM To: 'vkg@lucent.com'; Dvir Oren Cc: SIP Subject: RE: [SIP] OK with no ACK Vijay - How can a User Agent Server issue a Cancel? What Dvir is describing here is a UAS is trying to send 200 OK and never receives an ACK. It should just kill the call without having to send anything after retransmission time out. Mohammad Vakil OutReach Technologies -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@lucent.com] Sent: Thursday, July 06, 2000 10:33 AM To: Dvir Oren Cc: SIP Subject: Re: [SIP] OK with no ACK Dvir Oren wrote: > > I think that a situation where the calle sent OK, but doesn't receive > ACK for an extended period of time should be handled. I'm > implementing a timeout on OK replies, that will kill the call if no > ACK was received after a defined period of time. > > My question is, should I send a CANCEL or a BYE? I would send a CANCEL since the call has not been established until the ACK from the caller gets to the callee. That is the behavior of my proxy. A BYE (to me at least) conveys that a session was successfully established and is now being torn down. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 11:38:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18888 for ; Thu, 6 Jul 2000 11:38:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 941FA4444D; Thu, 6 Jul 2000 11:31:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 72CDD44449 for ; Thu, 6 Jul 2000 11:31:03 -0400 (EDT) Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA01428; Thu, 6 Jul 2000 16:29:13 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id QAA03865 for ; Thu, 6 Jul 2000 16:29:11 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Thu, 6 Jul 2000 16:29:11 +0000 (GMT) From: James Undery To: sip@lists.bell-labs.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Changes to SIP server location Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I've noticed in the July version of the bis draft section 1.4.2 says "... If there is no port number in the URI, the default port, 5060, is used." step 4 of the algorithm following that says, "The Request-URI is examined. If it contains an explicit port number other than 5060, the next two steps are skipped." the next two steps are SRV lookups. My question is why if the default port is explicitly specified would you want to do SRV record lookups? If there is a sensible answer to that why doesn't it apply to all other explicit ports? James Undery _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 11:58:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19419 for ; Thu, 6 Jul 2000 11:58:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 331E44434F; Thu, 6 Jul 2000 11:57:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 946C344338 for ; Thu, 6 Jul 2000 11:57:49 -0400 (EDT) Received: (qmail 4961 invoked by uid 1002); 6 Jul 2000 15:56:54 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Jul 2000 18:56:53 +0300 (IDT) To: "Vakil, Mohammad" Cc: SIP Subject: RE: [SIP] OK with no ACK In-Reply-To: <91522176F94CD4119FAB00B0D0492B4312AC85@ORT-EXCH> References: <91522176F94CD4119FAB00B0D0492B4312AC85@ORT-EXCH> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14692.43786.169871.308947@jodie.lucid> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Vakil, Mohammad writes ("RE: [SIP] OK with no ACK"): > You don't send a CANCEL or BYE if don't receive any ACK to your 200 OK. You > can just kill the call after retransmission timer runs out. But you MUST > keep retransmitting 200 OK until timer runs out. This would leave the other end dangling. Maybe I'll draw a scenario: A --- INVITE ---> B <-- RINGING --- --- OK ---> --- OK ---> --- OK ---> (timeout) (quietly dies) If 'B' will quietly die at this point, 'A' will never be able to leave its 'Ringing' state. I imagine that if there is a user at 'A', he/she will at some point tire of hearing the 'ring', and simply hang up. However, if there is no user at 'A' (the most immediate scenario is in debugging!), then 'A' will never leave this state. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 12:15:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19792 for ; Thu, 6 Jul 2000 12:15:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 373F4443EC; Thu, 6 Jul 2000 12:14:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 6B7BB44338 for ; Thu, 6 Jul 2000 12:14:54 -0400 (EDT) Received: (qmail 5017 invoked by uid 1002); 6 Jul 2000 16:14:00 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Jul 2000 19:13:58 +0300 (IDT) To: SIP X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14692.44660.572998.305448@jodie.lucid> Subject: [SIP] Proxy replies to BYE Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Should a Proxy reply to a BYE? If it doesn't reply to the BYE, then everybody along the path will keep retrnasmitting the BYE until the OK reaches from the other end. This does not seem like proper behavior to me. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 12:35:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20389 for ; Thu, 6 Jul 2000 12:35:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B22544405; Thu, 6 Jul 2000 12:34:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7BFFB44338 for ; Thu, 6 Jul 2000 12:34:50 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA12293; Thu, 6 Jul 2000 12:36:13 -0400 (EDT) Message-ID: <3964B5C2.6C9FA144@dynamicsoft.com> Date: Thu, 06 Jul 2000 12:37:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Cc: SIP Subject: Re: [SIP] Proxy replies to BYE References: <14692.44660.572998.305448@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir Oren wrote: > > Should a Proxy reply to a BYE? Absolutely NOT. The only response a proxy would send is a 100 Trying. Proxies do not send final responses to requests, INVITE, BYE or otherwise. > > If it doesn't reply to the BYE, then everybody along the path will > keep retrnasmitting the BYE until the OK reaches from the other end. > This does not seem like proper behavior to me. No, this is correct in the end to end model, which is what we have here. As BYE responses are generally automatic, you won't usually see even a single BYE retransmission, since the response will come within 4 seconds (the 100 Trying from each proxy will cause the BYE retransmission rate to increase to 4 seconds). -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 12:37:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20433 for ; Thu, 6 Jul 2000 12:37:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EEE4B44414; Thu, 6 Jul 2000 12:36:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ort-exch.outreachtech.com (unknown [208.246.106.18]) by lists.bell-labs.com (Postfix) with ESMTP id 21DD84440A for ; Thu, 6 Jul 2000 12:36:19 -0400 (EDT) Received: by ORT-EXCH with Internet Mail Service (5.5.2650.21) id <3MW44VZ4>; Thu, 6 Jul 2000 12:36:04 -0400 Message-ID: <91522176F94CD4119FAB00B0D0492B4312AC89@ORT-EXCH> From: "Vakil, Mohammad" To: "'Dvir Oren'" , "Vakil, Mohammad" Cc: SIP Subject: RE: [SIP] OK with no ACK Date: Thu, 6 Jul 2000 12:36:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Dvir - Ringing is a provisonal response. I'd stop retransmission of INVITE on receiving Ringing but I'd not stop my Timer. And I'd send a CANCEL after timer runs out. The way I would implement is, I would remain in Inviting state until I receive a Final response. I wouldn't go to a provisional state. Mohammad Vakil OutReach Technologies -----Original Message----- From: Dvir Oren [mailto:dvir@lucidvon.com] Sent: Thursday, July 06, 2000 11:57 AM To: Vakil, Mohammad Cc: SIP Subject: RE: [SIP] OK with no ACK Vakil, Mohammad writes ("RE: [SIP] OK with no ACK"): > You don't send a CANCEL or BYE if don't receive any ACK to your 200 OK. You > can just kill the call after retransmission timer runs out. But you MUST > keep retransmitting 200 OK until timer runs out. This would leave the other end dangling. Maybe I'll draw a scenario: A --- INVITE ---> B <-- RINGING --- --- OK ---> --- OK ---> --- OK ---> (timeout) (quietly dies) If 'B' will quietly die at this point, 'A' will never be able to leave its 'Ringing' state. I imagine that if there is a user at 'A', he/she will at some point tire of hearing the 'ring', and simply hang up. However, if there is no user at 'A' (the most immediate scenario is in debugging!), then 'A' will never leave this state. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 13:07:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21233 for ; Thu, 6 Jul 2000 13:07:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A3DFA44406; Thu, 6 Jul 2000 13:07:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id C9E3044338 for ; Thu, 6 Jul 2000 13:07:03 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id NAA00485; Thu, 6 Jul 2000 13:06:59 -0400 (EDT) Message-ID: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> From: "Brett Tate" To: "SIPbell-labs" Date: Thu, 6 Jul 2000 13:10:26 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0372_01BFE74B.8D3864F0" 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] Deleting Media Streams section in rfc2543bis Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0372_01BFE74B.8D3864F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Appendix B.5 in rfc2543bis (July 1, 2000) mentions that=20 a media stream is deleted by setting the port to 0. It=20 would be worth mentioning in this section that a media=20 stream can also be deleted by the absence of a "m=3D..."=20 line which was in the previous SDP for the call leg. It might also be worth mentioning somewhere in=20 Appendix B that receiving a completely new SDP within=20 a call-leg should render the previous SDP obsolete. If these comments are incorrect, please reply. ------=_NextPart_000_0372_01BFE74B.8D3864F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Appendix B.5 in rfc2543bis (July 1, 2000) mentions = that=20
a media stream is deleted by setting the port to = 0.  It=20
would be worth mentioning in this section that a = media=20
stream can also be deleted by = the absence=20 of a "m=3D..."
line which was in the = previous SDP=20 for the call leg.
 
It might also be worth mentioning somewhere in =
Appendix B that receiving a completely new SDP = within=20
a call-leg should render the previous SDP=20 obsolete.
 
If these comments are incorrect, please reply.
 
------=_NextPart_000_0372_01BFE74B.8D3864F0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 13: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 ESMTP id NAA21723 for ; Thu, 6 Jul 2000 13:39:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D4644440A; Thu, 6 Jul 2000 13:38:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id A937444338 for ; Thu, 6 Jul 2000 13:38:42 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA05886; Thu, 6 Jul 2000 13:38:37 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA10619; Thu, 6 Jul 2000 13:38:36 -0400 (EDT) Message-ID: <3964C41C.558236F@cs.columbia.edu> Date: Thu, 06 Jul 2000 13:38:36 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Undery Cc: sip@lists.bell-labs.com, Igor Slepchin Subject: Re: [SIP] Changes to SIP server location References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Undery wrote: > > Hi, > > I've noticed in the July version of the bis draft section 1.4.2 > says > > "... If there is no port number in the URI, the default port, 5060, is > used." > > step 4 of the algorithm following that says, > > "The Request-URI is examined. If it contains an explicit port number other > than 5060, the next two steps are skipped." > > the next two steps are SRV lookups. > > My question is why if the default port is explicitly specified would you > want to do SRV record lookups? If there is a sensible answer to that why > doesn't it apply to all other explicit ports? This has been discussed extensively on the list, I believe. Has to do with comparisons of URLs, where having foo:5060 and foo being different is strange. The advantages of bypassing SRV, whatever they might be, didn't seem to outweigh the confusion of having the default port and its absence be different. I seem to remember Igor Slepchin bringing this up last time around. -- 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 Jul 6 13:40:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21775 for ; Thu, 6 Jul 2000 13:40:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EAC94441E; Thu, 6 Jul 2000 13:40:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 8A79944419 for ; Thu, 6 Jul 2000 13:39:58 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA21601; Thu, 6 Jul 2000 10:40:10 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAB48659; Thu, 6 Jul 2000 10:39:56 -0700 (PDT) Message-Id: <4.2.0.58.20000706101059.00cb2f10@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 06 Jul 2000 10:39:10 -0700 To: "Alex Hardisty" From: Rohan Mahy Subject: RE: [SIP] on directed pick up service Cc: "Jonathan Rosenberg" , "Jo Hornsby" , "Krishna G" , In-Reply-To: References: <39640839.73912D4D@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Alex, How can you be sure you will get these interoperable features using the ITU approach? You can't. The H.323 family of protocols has specified individual features in the H.450 series, however very few vendors have bothered to implement most of this because it is a lot of work for each additional feature. In other words, there is very little market incentive to build new services using this approach. Now compare that to the Internet. If someone wants a new service, they build it. Perhaps they need to extend an existing protocol, so they write an Internet Draft on it. If the service is compelling, then people will use the service. If people use the service, others will build in support for the service, or offer a competing service. Service A may not work exactly like service B, but user A may pick service B because they like the way it works. To be more specific to this example, a few folks on the list wrote about how you could implement "xyz" feature *without changing the exisiting protocol*. That should be clue #1 that something good is going on. Now you can go ask vendors for "xyz" feature on their UA, xyz registration feature on the proxy, xyz tool for easily administering this, etc. You can do it yourself, you can go to one vendor, you can hire an integrator to do that work, whatever you want. thanks, -rohan At 02:20 AM 7/6/00 , Alex Hardisty wrote: >Jonathan Rosenberg wrote: > > > The service definition is whatever you want it to be. We here at IETF > > don't specify services, but rather protocols to support services. > >But don't you have to know what the service is and how it behaves before you >can define the protocol to support it? Or at least, have some specification >of the characteristics of the group of services for which you want to define >a general protocol? > >To me this lack of service descriptions appears to be a weakness of the IETF >approach. If I buy SIP phones from one vendor, a SIP PBX from another vendor >and a SIP based voicemail server from somewhere else, how can I be sure of >interoperability between them? How can I be sure they will handle, for >example, call transfer, call forwarding, and message waiting in a consistent >manner? > >What happens as the services start to become more complex, perhaps involving >many different server types? Services in the mobility area (both terminal >and personal mobility) typically involve upto 8 different functional >entities with many detailed information flows between them. If there is no >specification for how the service should work, how will a major corporation >establish a Worldwide service to provide corporate mobility with equipment >sourced from several vendors? > >-- >Alex Hardisty >PQM Consultants > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/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 Jul 6 14: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 ESMTP id OAA22402 for ; Thu, 6 Jul 2000 14:15:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56A044440A; Thu, 6 Jul 2000 14:14:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from june.idc1.level3.com (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 6ABF044338 for ; Thu, 6 Jul 2000 14:14:14 -0400 (EDT) Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140]) by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id SAA26572; Thu, 6 Jul 2000 18:14:12 GMT From: Jon.Peterson@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id MAA03770; Thu, 6 Jul 2000 12:14:11 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jul 2000 12:15:52 -0600 Message-ID: <87A245E94948D3118DE30008C716B01301523A06@c0005v1idc1.oss.level3.com> To: Gonzalo.Camarillo@lmf.ericsson.se Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: RE: [SIP] QoS & Third Party Call Control in SIP Date: Thu, 6 Jul 2000 12:14:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At the risk of belaboring the point, I believe that once the preconditions have been met in the flow illustrated earlier in the thread (i.e. COMETs have been exchanged), C has no control over the order of operations; i.e. whether A or B will connect to the session first. For at least some services, telephones being one, it may make sense for C to enforce a particular order of operations - C may want A to connect to the session before B. If order of operations is essential to a particular service with preconditions, then perhaps a similar flow might be constructed in which it is guaranteed that A will provide a final response before B has the opportunity to begin alerting. Moreover, it is not clear to me how 3pcc SIP could guarantee the simultaneity of final responses from A or B, regardless of preconditions, for a service such as the camera and storage device that must connect at the same time. Clearly, A or B simply might not be able to join the session for reasons unrelated to qos or security. I think the best you can do is choose one to go first - satisfaction of preconditions is not, as I understand it, an indication that the entity in question will actually join the session. Jon Peterson Level(3) Communications -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Thursday, July 06, 2000 1:07 AM To: Peterson, Jon Cc: jdrosen@dynamicsoft.com; sip@lists.bell-labs.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP Hi, Jon.Peterson@Level3.com wrote: > > I have a question about the flow below. When C has acquired the provisional > media (183) SDP from A, is that the time at which C would like to send an > INVITE to B? Or would C rather wait until someone actually picks up the > phone at A? The idea is to establish a session between A and B. The presence of C should be transparent to the user plane. So, C issues the INVITE without waiting for A to pick up the phone. In fact, A's phone is not ringing, since the preconditions are not met yet. Third party control is useful not just for "telephones". A might be, for instance, a SIP video camera and B a storage device. We do not want the storage device to begin recording until the camera begins filming (nor the other way around)... Jonathan Rosenberg wrote: > Well, C can't send an ACK since there is no final response yet. It could > include the update SDP in the PRACK, in which case you wouldn't need to > do a re-INVITE. I like better the PRACK solution than the re-INVITE approach. PARCKs would provide a way of updating SDPs from the UAC towards the UAS. In some situations this is very useful. 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/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 Jul 6 14: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 ESMTP id OAA22547 for ; Thu, 6 Jul 2000 14:22:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C8E144426; Thu, 6 Jul 2000 14:21:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pop-rocks.shoretel.com (pop-rocks.shoretel.com [208.163.34.3]) by lists.bell-labs.com (Postfix) with ESMTP id C58B344414 for ; Thu, 6 Jul 2000 14:21:56 -0400 (EDT) Received: by pop-rocks.shoretel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jul 2000 11:17:34 -0700 Message-ID: From: Amar Singh To: "'Jonathan Rosenberg'" , Jo Hornsby Cc: Krishna G , sip@lists.bell-labs.com Subject: RE: [SIP] on directed pick up service Date: Thu, 6 Jul 2000 11:17:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com How does directed pickup work when redirect server is used instead of proxy server. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 05, 2000 9:17 PM To: Jo Hornsby Cc: Krishna G; sip@lists.bell-labs.com Subject: Re: [SIP] on directed pick up service Jo Hornsby wrote: > > > > Basically, a typical call flow for such a scenario would be: > > > > > > A --INVITE--> P B --INVITE--> C > > > --INVITE--> > > > <---180---- > > > <--RINGING- > > > (At this point, User 2 hears B ringing from C) > > > <--------REGISTER-------- > > > -----------200----------> > > > ----------INVITE--------> > > > <--------RINGING--------- > > > <----------200----------- > > > --CANCEL--> > > > (yada yada) > > > > > > (In the above case, P is a forking proxy that CANCELs pending > > > branches upon reception of a 200 response, and which also acts as > > > a Registrar.) > > > > *** Now how does C know that it has to send the REGISTER request to P? > > Blind faith. &:) > > But seriously, this is where things potentially break-down, or not. > Something like "Directed Pick-Up" (if indeed that is the correct > term) does require some sort of sane configuration/application. How is it done in the circuit switched world? After all, both phones need to be part of the same PBX for this to work. Well, both terminals are hard wired to the same PBX. You can think of that as the ultimate in hardcoded configuration. The same is true here. As Jo has correctly pointed out, the service works assuming that both phones are configured to use the same proxy server. Alex Hardisty writes: > 2) Directed call pick-up requires me to enter the number of the telephone > that is ringing, so am I entering the number of the UA or am I entering my > personal number? If the latter it's not Directed Call Pickup but Personal > User Mobility. What's the service definition here? The service definition is whatever you want it to be. We here at IETF don't specify services, but rather protocols to support services. If the service you want is something as close as possible to existing call pickup, you can do that. A terminal is typically associated with a number, and would register itself as the handler for that number: REGISTER sip:example.com SIP/2.0 To: sip:1234@example.com Contact: sip:1234@phone23827304-8762.example.com The phone for extension 4321 would normally send a similar registration: REGISTER sip:example.com SIP/2.0 To: sip:4321@example.com Contact: sip:4321@phone11223344556677.example.com when I am sitting at extension 4321, and hear 1234 ringing, and want to pick it up, I would dial the appropriate service code and then enter the extension I want to pick up. This would cause that phone to send an additional register: REGISTER sip:example.com SIP/2.0 To: sip:1234@example.com Contact: sip:4321@phone11223344556677.example.com Now, this terminal begins to ring also and I can pick it up. Note that the "smarts" for this service are actually distributed; some of it is in the UA (which needs to know to send registers formatted this way when implementing the directed pickup service), and some in the proxy (which is doing normal registrations). > One point I neglected to mention before was that this isn't > exactly the same as "Directed Pick-Up" (in my experience of the > term), anyway. P may send an additional INVITE to C, but that > doesn't mean that B stops ringing (indeed, I can imagine > situations where that would be completely undesirable -- > preemptively registering a holiday address, for example -- since > User 2's call would suddenly "disappear"). It's only once User 2 > picks up from C, that B _might_ stop ringing. Correct. Note however, that causing the original terminal to stop ringing can also be achieved with some additional smarts in the phones, sending an additional REGISTER to unregister the original address... -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 15: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 ESMTP id PAA23789 for ; Thu, 6 Jul 2000 15:17:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8B9144357; Thu, 6 Jul 2000 15:16:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id BD88444338 for ; Thu, 6 Jul 2000 15:16:53 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA08492 for ; Thu, 6 Jul 2000 12:17:05 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAB50363; Thu, 6 Jul 2000 12:16:51 -0700 (PDT) Message-Id: <4.2.0.58.20000706104920.00de0af0@lint.cisco.com> X-Sender: rmahy@lint.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 06 Jul 2000 12:16:05 -0700 To: sip@lists.bell-labs.com From: Rohan Mahy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] harmonized SUBSCRIBE/NOTIFY behavior Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I'm looking for some consistent direction on SUBSCRIBE/NOTIFY. Since we have the SUBSCRIBE/NOTIFY draft, PINT, and IMPP for presence, all doing stuff differently. I can see valid reasons for each of these cases: a subscribe to ongoing state, I already know the current state b subscribe to ongoing state, plus get current state c refresh subscription, I know the current state d refresh subscription, plus get current state e fetch the current state f unsubscribe Hopefully Jonathan Rosenberg, Scott Petrack, and Adam Roach have all talked about this somewhere. My interetation of the currently available documents is that they can do this: SUB/NFY a, c, f PINT a, c, e, f IMPP b, c, e, f Perhaps we need a new header/parameter used in a SUBSCRIBE that indicates whether to send back immediate status? Also, the use of an Event header, Call-ID usage, and body handling are not consistent, but this seems like less of an issue. Anyone care to clarify? Will the three documents be harmonized (apologies for using an ITU term) at some point? Relevant sections of the documents are included below. Also, a short comment on IMPP inline... thanks, -rohan In draft-roach-sip-subscribe-notify-00.txt, the author asks: >Should cancelling a subscription be performed with the UNSUBSCRIBE method >defined in PINT for the sake of consistency, or is the REGISTER model of >"Expires: 0" preferable? There is no mention of the SUBSCRIBE response carrying back any state. In the companion document, draft-roach-sip-acb-00.txt, a SUBSCRIBE to the "terminal-free" event does not necessarily need state in the reply, because presumably, the subscriber already assumed the terminal wan't free, because they got a busy signal. In RFC2848, the authors state: >When a SUBSCRIBE request is sent to a PINT Server, it indicates that a >user wishes to receive information about the status of a service session. >The request identifies the session of interest by including the original >session description along with the request, using the SDP >global-session-id that forms part of the origin-field to identify the >service session uniquely. >Rather than have two different methods of identifying the "session of >interest" the choice is to use the origin-field of the SDP sub-part >included both in the original INVITE and in this SUBSCRIBE request. > >Note that the request MUST NOT include any sub-parts other than the >session description, even if these others were present in the original >INVITE request. A server MUST ignore whatever sub-parts are included >within a SUBSCRIBE request with the sole exception of the enclosed session >description. The request MAY contain a "Contact:" header, specifying the >PINT User Agent Server to which such information should be sent. > >In addition, it SHOULD contain an Expires: header, which indicates for how >long the PINT Requestor wishes to receive notification of the session >status. We refer to the period of time before the expiration of the >SUBSCRIBE request as the "subscription period". See section 5.1.4. for >security considerations, particularly privacy implications. > >A value of 0 within the Expires: header indicates a desire to receive one >single immediate response (i.e. the request expires immediately). It is >possible for a sequence of monitoring sessions to be opened, exist, and >complete, all relating to the same service session. > >A successful response to the SUBSCRIBE request includes the session >description, according to the Gateway. Normally this will be identical to >the last cached response that the Gateway returned to any request >concerning the same SDP global session id (see [2], section 6, o= field). >The t= line may be altered to indicate the actual start or stop time, >however. The Gateway might add an i= line to the session description to >indicate such information as how many fax pages were sent. The Gateway >SHOULD include an Expires: header indicating how long it is willing to >maintain the monitoring session. If this is unacceptable to the PINT >Requestor, then it can close the session by sending an immediate >UNSUBSCRIBE message (see 3.5.3.3). >At some point, either the Client's representative User Agent Server or the >Gateway may decide to terminate the monitoring session. This is achieved >by sending an UNSUBSCRIBE request to the correspondent server. Such a >request indicates that the sender intends to close the monitoring session >immediately, and, on receipt of the final response from the receiving >server, the session is deemed over. > >Note that unlike the SUBSCRIBE request, which is never sent by a PINT >gateway, an UNSUBSCRIBE request can be sent by a PINT gateway to the User >Agent Server to indicate that the monitoring session is closed. (This is >analogous to the fact that a gateway never sends an INVITE, although it >can send a BYE to indicate that a telephone call has ended.) > >If the Gateway initiates closure of the monitoring session by sending an >UNSUBSCRIBE message, it SHOULD include an "Expires:" header showing for >how much longer after this monitoring session is closed it is willing to >store information on the service session. This acts as a minimum time >within which the Client can send a new SUBSCRIBE message to open another >monitoring session; after the time indicated in the Expires: header the >Gateway is free to dispose of any record of the service session, so that >subsequent SUBSCRIBE requests can be rejected with a "606" response. > >If the subscription period specified by the Client has expired, then the >Gateway may send an immediate UNSUBSCRIBE request to the Client's >representative User Agent Server. This ensures that the monitoring session >always completes with a UNSUBSCRIBE/response exchange, and that the >representative User Agent Server can avoid maintaining state in certain >circumstances. In draft-rosenberg-impp-presence-00.txt, the authors state: >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. Jonathan, instead of the first sentence I propose something like this: "A SUBSCRIBE request MUST contain a Contact header, unless the SUBSCRIBE request is used for Fetching currect state only (see section 5.8)." OR "An ordinary SUBSCRIBE request MUST contain a Contact header. A SUBSCRIBE request without a Contact is used for Fetching current state only, and does not cause notifications." >[When replying to a new subscription,] The 200 OK response SHOULD also >contain a copy of the current presence state of the presentity. >A subscriber may unsubscribe by sending a SUBSCRIBE request with an >Expires header of 0. The Contact header indicates the particular address >that is being unsubscribed. This MAY be a *, indicating that all Contacts >for that particular subscription (as identified by the Call-ID, To, and >From) are to be removed. If all Contacts are removed, the PA deletes the >subscription. >Fetching is similar to a subscribing, in that it returns the current >presence state. However, no notifications are sent for future changes in >the presence state. Rather than inventing a new method for this, it is >readily accomplished with a SUBSCRIBE along with an Expires: 0 header and >no Contact header. The absence of any Contact header is what distinguishes >it from the similar operation of unsubscribing. The advantage of using >SUBSCRIBE is that the server can simply process the request independently >of whether its a fetch or longer lived subscription; the authorization and >processing steps are identical. The only difference is whether an actual >subscription is instantiated for the user or not. > >This parallels how fetching of registrations is done in SIP. Note that >fetching has no effect on existing subscriptions. 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 Thu Jul 6 15:22:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23894 for ; Thu, 6 Jul 2000 15:22:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AEDF44430; Thu, 6 Jul 2000 15:22:08 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 5B53744419 for ; Thu, 6 Jul 2000 15:22:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jul 6 15:21:37 EDT 2000 Received: by lists.bell-labs.com (Postfix) id CA71844354; Thu, 6 Jul 2000 15:08:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 6C4A244347 for ; Thu, 6 Jul 2000 15:08:28 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA02108; Thu, 6 Jul 2000 14:08:24 -0500 Cc: "Vakil, Mohammad" , Dvir Oren , SIP Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA02063; Thu, 6 Jul 2000 14:08:19 -0500 Message-ID: <3964D923.A06BC089@lucent.com> Date: Thu, 06 Jul 2000 14:08:19 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Agboh, Charles" Original-CC: "Vakil, Mohammad" , Dvir Oren , SIP Subject: Re: [SIP] OK with no 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Boy, am I off today. I meant if the "callee" does not receive an ACK to the 200 OK it send out in response to the INVITE it got. There, I hope I said that correctly. Need to get some more coffee or a better brand of it... "Agboh, Charles" wrote: > > Callers don't receive ACKs unless they received an invite from the callee. > > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Thursday, July 06, 2000 5:06 PM > To: Vakil, Mohammad > Cc: Dvir Oren; SIP > Subject: Re: [SIP] OK with no ACK > > "Vakil, Mohammad" wrote: > > > > Vijay - > > > > How can a User Agent Server issue a Cancel? What Dvir is describing > > here is a UAS is trying to send 200 OK and never receives an ACK. It > > should just kill the call without having to send anything after > > retransmission time out. > > Mohammad: > > You are correct; I mistook Dvir's scenario for another context that I > have been thinking about recently (when you have a hammer, everything > looks like a nail...). Clearly, in case of an INVITE if the caller does > not receive an ACK to the 200 OK, it will keep on re-transmitting the > 200 OK until it has exhausted its retry limit. > > Sorry for the confusion > > - vijay _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 16:10:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24611 for ; Thu, 6 Jul 2000 16:10:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7735144414; Thu, 6 Jul 2000 16:10:06 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 1305844338 for ; Thu, 6 Jul 2000 16:10:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jul 6 16:08:45 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2FDD144354; Thu, 6 Jul 2000 15:55:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id D17A244347 for ; Thu, 6 Jul 2000 15:55:35 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21402; Thu, 6 Jul 2000 14:55:31 -0500 Cc: "Vakil, Mohammad" , Dvir Oren , SIP Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21387; Thu, 6 Jul 2000 14:55:28 -0500 Message-ID: <3964E42F.28820A03@lucent.com> Date: Thu, 06 Jul 2000 14:55:27 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Original-CC: "Vakil, Mohammad" , Dvir Oren , SIP Subject: Re: [SIP] OK with no ACK References: <91522176F94CD4119FAB00B0D0492B4312AC87@ORT-EXCH> <3964A355.4535A9C7@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I think Vijay is saying that his proxy sends a CANCEL if it doesn't > see the ACK before the timeout fires. [...] > Mohammed is also correct that the UAS never sends a CANCEL for a > request it receives. Jonathan: Please read; there's a question for you towards the end. When I read Dvir's original question, which was -- "should I send a CANCEL or a BYE?" -- I assumed he was asking what should the CALLER do after sending out an INVITE and not yet receiving a 200 OK. So, in that context, I think after the seventh retransmission attempt (for UDP) or an appropriate timeout (for TCP), the caller should send a CANCEL and NOT a BYE. As I said before, to me a BYE is semantically equivalent to the fact that an session was established already which is now being torn down. A CANCEL cancels a pending request (i.e. a request for which a final status response has not been received yet). However, the RFC (June 9 bis, Section 10.5.1) says that a UAC may send a BYE or CANCEL after the seventh retransmission. RFC 2543 is silent on this (Section 10.5.1). Jonathan: don't know if you will recall, but during April 2000 bakeoff, I had a conversation with you where I came to the conclusion that CANCEL is the appropriate request to send in this case. But the June 9 bis RFC indicates that a BYE is just as appropriate. Should we finalize on one of CANCEL or BYE in cases like this? Or is it too much trouble to codify such cases and prescribe behavior? Thanks, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 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 Jul 6 16:15:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24681 for ; Thu, 6 Jul 2000 16:15:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D76C94442F; Thu, 6 Jul 2000 16:14:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 62C7244420 for ; Thu, 6 Jul 2000 16:14:25 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA22360; Thu, 6 Jul 2000 13:14:37 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAB51198; Thu, 6 Jul 2000 13:14:24 -0700 (PDT) Message-Id: <4.2.0.58.20000706130748.00ded100@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 06 Jul 2000 13:13:37 -0700 To: Amar Singh From: Rohan Mahy Subject: RE: [SIP] on directed pick up service Cc: "'Jonathan Rosenberg'" , Jo Hornsby , Krishna G , sip@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Everyone involved in pickups could all use multicast for registrations and listen for registrations involving heir calls. However, IMO it's much easier to set this up with a proxy. This is a bit like saying "Here is how to protect stone, wood, brick, and steel buildings from huricanes", and then asking how to protect a grass hut from huricances. You can do it, but it is hard. If your goal is huricane protection, use building materials suitable for easily attaining your goal. If you want SIP features and services requiring some centralized knowledge, take advantage of forking proxies. thanks, -rohan At 11:17 AM 7/6/00 , Amar Singh wrote: >How does directed pickup work when redirect server is used instead of proxy >server. > >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: Wednesday, July 05, 2000 9:17 PM >To: Jo Hornsby >Cc: Krishna G; sip@lists.bell-labs.com >Subject: Re: [SIP] on directed pick up service > > > > >Jo Hornsby wrote: > > > > > > Basically, a typical call flow for such a scenario would be: > > > > > > > > A --INVITE--> P B --INVITE--> C > > > > --INVITE--> > > > > <---180---- > > > > <--RINGING- > > > > (At this point, User 2 hears B ringing from C) > > > > <--------REGISTER-------- > > > > -----------200----------> > > > > ----------INVITE--------> > > > > <--------RINGING--------- > > > > <----------200----------- > > > > --CANCEL--> > > > > (yada yada) > > > > > > > > (In the above case, P is a forking proxy that CANCELs pending > > > > branches upon reception of a 200 response, and which also acts as > > > > a Registrar.) > > > > > > *** Now how does C know that it has to send the REGISTER request to P? > > > > Blind faith. &:) > > > > But seriously, this is where things potentially break-down, or not. > > Something like "Directed Pick-Up" (if indeed that is the correct > > term) does require some sort of sane configuration/application. > >How is it done in the circuit switched world? After all, both phones >need to be part of the same PBX for this to work. Well, both terminals >are hard wired to the same PBX. You can think of that as the ultimate in >hardcoded configuration. The same is true here. As Jo has correctly >pointed out, the service works assuming that both phones are configured >to use the same proxy server. > >Alex Hardisty writes: > > 2) Directed call pick-up requires me to enter the number of the telephone > > that is ringing, so am I entering the number of the UA or am I entering my > > personal number? If the latter it's not Directed Call Pickup but Personal > > User Mobility. What's the service definition here? > >The service definition is whatever you want it to be. We here at IETF >don't specify services, but rather protocols to support services. > >If the service you want is something as close as possible to existing >call pickup, you can do that. A terminal is typically associated with a >number, and would register itself as the handler for that number: > >REGISTER sip:example.com SIP/2.0 >To: sip:1234@example.com >Contact: sip:1234@phone23827304-8762.example.com > >The phone for extension 4321 would normally send a similar registration: > >REGISTER sip:example.com SIP/2.0 >To: sip:4321@example.com >Contact: sip:4321@phone11223344556677.example.com > >when I am sitting at extension 4321, and hear 1234 ringing, and want to >pick it up, I would dial the appropriate service code and then enter the >extension I want to pick up. This would cause that phone to send an >additional register: > >REGISTER sip:example.com SIP/2.0 >To: sip:1234@example.com >Contact: sip:4321@phone11223344556677.example.com > >Now, this terminal begins to ring also and I can pick it up. > > >Note that the "smarts" for this service are actually distributed; some >of it is in the UA (which needs to know to send registers formatted this >way when implementing the directed pickup service), and some in the >proxy (which is doing normal registrations). > > > > One point I neglected to mention before was that this isn't > > exactly the same as "Directed Pick-Up" (in my experience of the > > term), anyway. P may send an additional INVITE to C, but that > > doesn't mean that B stops ringing (indeed, I can imagine > > situations where that would be completely undesirable -- > > preemptively registering a holiday address, for example -- since > > User 2's call would suddenly "disappear"). It's only once User 2 > > picks up from C, that B _might_ stop ringing. > >Correct. Note however, that causing the original terminal to stop >ringing can >also be achieved with some additional smarts in the phones, sending an >additional REGISTER to unregister the original address... > >-Jonathan R. >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 6 16:18:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24736 for ; Thu, 6 Jul 2000 16:18:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4B09F44445; Thu, 6 Jul 2000 16:17:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 762DB4443B for ; Thu, 6 Jul 2000 16:17:10 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA21157; Thu, 6 Jul 2000 16:17:08 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA15747; Thu, 6 Jul 2000 16:17:06 -0400 (EDT) Message-ID: <3964E942.6F03ED41@cs.columbia.edu> Date: Thu, 06 Jul 2000 16:17:06 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: vkg@lucent.com Cc: Jonathan Rosenberg , "Vakil, Mohammad" , Dvir Oren , SIP Subject: Re: [SIP] OK with no ACK References: <91522176F94CD4119FAB00B0D0492B4312AC87@ORT-EXCH> <3964A355.4535A9C7@dynamicsoft.com> <3964E42F.28820A03@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Vijay K. Gurbani" wrote: > > > RFC indicates that a BYE is just as appropriate. Should we finalize on > one of CANCEL or BYE in cases like this? Or is it too much trouble to > codify such cases and prescribe behavior? > It just doesn't matter. In either case, the callee (receiver of the BYE) will remove call state, if any existed. The only drawback of CANCEL is that there is a small chance that the callee had sent a 200 and all of them got lost. The callee will then ignore the CANCEL. In that case, you'd have to send a BYE when the 200 arrives, which is more trouble. -- 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 Jul 6 19: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 ESMTP id TAA27320 for ; Thu, 6 Jul 2000 19:13:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4059944357; Thu, 6 Jul 2000 19:13:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 094DB44338 for ; Thu, 6 Jul 2000 19:12:57 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA02621 for ; Thu, 6 Jul 2000 19:12:45 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA19375 for ; Thu, 6 Jul 2000 19:12:45 -0400 (EDT) Message-ID: <3965126D.E40A8E22@cs.columbia.edu> Date: Thu, 06 Jul 2000 19:12:45 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SRV library Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Since I was asked: We have an SRV-capable modification of the standard resparse library, available at http://www.cs.columbia.edu/~hgs/software/. This will hopefully encourage the support of SRV records in clients and servers. -- 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 Jul 6 20:46:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28137 for ; Thu, 6 Jul 2000 20:46:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A799544352; Thu, 6 Jul 2000 20:45:53 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 91EFA44338 for ; Thu, 6 Jul 2000 20:45:50 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA15547; Thu, 6 Jul 2000 20:47:19 -0400 (EDT) Message-ID: <39652839.A8CA501F@dynamicsoft.com> Date: Thu, 06 Jul 2000 20:45:45 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Brett Tate Cc: SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Brett Tate wrote: > It > would be worth mentioning in this section that a media > stream can also be deleted by the absence of a "m=..." > line which was in the previous SDP for the call leg. This is wrong: it cannot. The m= lines are never removed, otherwise you wouldn't be able to match m lines in response and request. Consider a situation where the request contains c=IN IP4 1.2.3.4 m=audio 54678 RTP/AVP 0 1 3 m=video 7346 RTP/AVP 10 13 (face) m=video 7880 RTP/AVP 10 11 (presentation) If the response contained something like m=audio 6540 RTP/AVP 0 1 m=video 6578 RTP/AVP 10 there would be no way to tell which of the two offered media streams was accepted and which one rejected. > It might also be worth mentioning somewhere in > Appendix B that receiving a completely new SDP within > a call-leg should render the previous SDP obsolete. See above. There is currently no way to completely replace SDP, you can only update it either by rejecting some media sessions (by setting their port # to 0) or by adding the new ones at the end of the list. 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 Jul 6 23:55:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02648 for ; Thu, 6 Jul 2000 23:55:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D33944352; Thu, 6 Jul 2000 23:55:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id F412C44336 for ; Thu, 6 Jul 2000 23:55:22 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id JAA00341 for ; Fri, 7 Jul 2000 09:24:34 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 07 Jul 2000 09:24:33 +0000 (IST) Received: from localhost (srinath@localhost) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id JAA05103 for ; Fri, 7 Jul 2000 09:24:25 +0530 (IST) Date: Fri, 7 Jul 2000 09:24:25 +0530 (IST) From: A Srinath To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Differant URL's in headers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I have a query regarding URLs of other schemes in the headers. 1. How does a user agent client send an INVITE to a TO conatianing, say a mailto URL or even an HTTP URL. What will be the Request-URI then. Srinath A Silicon Automation Systems Phone: 5276100, 5276108 extn 4220 #1309, 10th Main, HAL III Stage Bangalore 560 008, India _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 00:11:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02771 for ; Fri, 7 Jul 2000 00:11:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D1CD744358; Fri, 7 Jul 2000 00:11:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 96BE244336 for ; Fri, 7 Jul 2000 00:10:57 -0400 (EDT) Received: from dynamicsoft.com (1Cust203.tnt5.freehold.nj.da.uu.net [63.36.113.203]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA16080; Fri, 7 Jul 2000 00:12:13 -0400 (EDT) Message-ID: <396558E4.98C35081@dynamicsoft.com> Date: Fri, 07 Jul 2000 00:13:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: vkg@lucent.com, "Vakil, Mohammad" , Dvir Oren , SIP Subject: Re: [SIP] OK with no ACK References: <91522176F94CD4119FAB00B0D0492B4312AC87@ORT-EXCH> <3964A355.4535A9C7@dynamicsoft.com> <3964E42F.28820A03@lucent.com> <3964E942.6F03ED41@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > "Vijay K. Gurbani" wrote: > > > > > > RFC indicates that a BYE is just as appropriate. Should we finalize on > > one of CANCEL or BYE in cases like this? Or is it too much trouble to > > codify such cases and prescribe behavior? > > > > It just doesn't matter. In either case, the callee (receiver of the BYE) > will remove call state, if any existed. The only drawback of CANCEL is > that there is a small chance that the callee had sent a 200 and all of > them got lost. The callee will then ignore the CANCEL. In that case, > you'd have to send a BYE when the 200 arrives, which is more trouble. We have discussed the issue before, and agreed during the meetings to allow both, as currently specified. Here is the issue. If the caller wants to hang up a call, but hasn't yet received a final response, it can send a CANCEL or a BYE. Sending a BYE would seem easiest, but there are issues. First off, you won't have gotten a tag yet from the UAS, nor will you have received Record-Route or Contact headers (obtained in the 200 OK response). This means the BYE will be routed "afresh" by proxies. Its possible that routing logic may have changed (perhaps there was some time of day routing or randomized routing), in which case the BYE may reach a different set of participants than reached by the original INVITE. So, if the original INVITE forked, and reached A and B, and the BYE reaches B and C, B will send a 200 OK, and C a 481. The forking proxy forwards the 200 OK upstream, and the caller gets the 200 OK. However, A is still ringing, and might later send a 200 OK. This yield inconsistent call state, which will persist until the UAS times out, as it will never get an ACK. Sending CANCEL helps solve many of these problems. CANCEL will reach the same set of recipients as the original INVITE, and it doesn't need a REcord-Route or tag in it. The drawback, however, is that the CANCEL and a 200 OK from one of the UAS might pass on the wire. Thus, the UAC may still need to ACK the 200 OK, and then send BYE. The other drawback is that you wouldn't send CANCEL if the call was already established, you'd send BYE. Folks complained they didn't want to have state-dependent mechanisms for hanging up. Given the unlikelihood of the problems with sending BYE, it seems reasonable to allow 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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 00:41:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03153 for ; Fri, 7 Jul 2000 00:41:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9DD744363; Fri, 7 Jul 2000 00:41:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from empowertel.com (unknown [64.220.200.243]) by lists.bell-labs.com (Postfix) with ESMTP id AC5D744336 for ; Fri, 7 Jul 2000 00:41:13 -0400 (EDT) Received: from rajeev ([192.168.111.39]) by empowertel.com (8.9.3+Sun/8.9.3) with SMTP id VAA20033; Thu, 6 Jul 2000 21:39:01 -0700 (PDT) Reply-To: From: "Rajeev Gupta" To: "'Henry Sinnreich'" Cc: Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) Date: Thu, 6 Jul 2000 21:38:25 -0700 Message-ID: <006e01bfe7cd$30e3a340$276fa8c0@empowertel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Henry Sinnreich wrote: > Would you really have your analog phones controlled by the > Telco, rather then being able to point them to any SIP server > of your choice? 1) As far as I know, your analog phones *are* controlled by the telco. It is a dumb device, acting upon the stimulus of the network (controller). To a degree, a GCP phone (or an IAD that connects to an analog phone) would simulate similar functionality. 2) You have the choice today to run your SIP UA on your desktop connected to your ISP, and thus talk to any SIP server of your choice. Similarly, you could connect your GCP phone or IAD to any MGC that will talk to you. The protocol model (SIP vs GCP) does not imply a business model (open/free vs controlled/fee). 3) This is not a technical issue, rather a business issue of whether MGCs provide their service for free, like today's SIP servers. It is not hard to imagine that SIP servers will evolve to provide value-add services for a fee, just as some folks may deploy experimental MGCs that, like SIP proxies, provide free services (clearly net-to-net calls, that do not gateway to the PSTN, can be provided free of cost, and there are many examples of that today). 4) Given that you can use the "free" Internet for voice using the protocol of your choice (SIP, GCP, H.323, etc.), why then would you want a fee-based service? Clearly, this will be driven by additional values the service provider can deliver such as SLAs, QoS, enhanced services, etc. It seems you are mixing the SIP vs GCP argument with the business model of delivering services to users. Rajeev Gupta empowerTel Networks 475 Sycamore Drive, Milpitas, CA 95035 Phone: +1 408 519 7136 Fax: +1 408 519 7399 mailto:rajeev@empowertel.com http://www.empowertel.com Personally, I would always prefer a SIP Ethernet to black phone adapter that gives me free choice of service provider to xGCP phones controlled by the Telco as in old times. Would you really have your analog phones controlled by the Telco, rather then being able to point them to any SIP server of your choice? Henry >-----Original Message----- >From: Matt Holdrege [mailto:matt@ipverse.com] >Sent: Monday, July 03, 2000 4:06 PM >To: Henry Sinnreich >Cc: 'Neil Deason'; Gardell, Steve; sip@lists.bell-labs.com >Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) > > >At 02:47 PM 7/3/00 -0500, Henry Sinnreich wrote: >>Problems seem to arise when circuit switch vendors promote the >>softswitch as an "exterior" service platform, across the net. >>Even without going into the technical issues, it >seems we would >>then end up with a "Softswitchnet" instead of the >Internet. This >>seemed far fetched to me until I actually heard a >circuit switch >>vendor promoting the "Next Generation Public Network" that >>actually went so far as to discard the Internet completely! > >There is nothing we can do about vendor marketing >approaches here. > >>More problems arise when a GC is promoted to control >IP phones. >>In this case, a competitor to the operator for that >GC could not >>extend features to the GC controlled phones. This is a prime >>example of fogging up the Internet, actually of reinventing >>unequal access at the control level. Besides, how do you >>integrate the services of xGCP phones with other >services on the >>Internet? > >There is nothing we can do about competitive control >of phones or services >here. All we can do is build protocols. How they are >used in the above >context is way outside our scope. > >>The above may be mistaken opinions, but there are >also questions >>such as, how does a softswitch environment handle: >>Presence? >>Instant Messaging? >>Unified Messaging? >>Caller and called preferences? >>Mobility? > >The Softswitch could incorporate each of those >features. But the more >likely scenario is that they would use SIP to >communicate to ASP's that >provide those features. A SIP phone may not need a >softswitch to do this, >but the umpteen billion non-SIP phones need a little help. > >This style of open service delivery is one of the >great things about our >next-gen architecture. > >>Some time ago, SIP and H.323 comparisons were made in a number >>of places. Is it now time to make SIP-softswitch comparisons? > >SIP and Softswitches are not mutually exclusive. >Pretty much all >Softswitches speak SIP now or will in the near future. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/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 Jul 7 01:31:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07265 for ; Fri, 7 Jul 2000 01:31:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E394044368; Fri, 7 Jul 2000 01:30:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 5B90044336 for ; Fri, 7 Jul 2000 01:30:51 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e675Unb20327; Fri, 7 Jul 2000 07:30:49 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA18883; Fri, 7 Jul 2000 08:30:48 +0300 (EET DST) Message-ID: <39656ACE.6D427F93@lmf.ericsson.se> Date: Fri, 07 Jul 2000 08:29:50 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jon.Peterson@Level3.com Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP References: <87A245E94948D3118DE30008C716B01301523A06@c0005v1idc1.oss.level> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Jon.Peterson@Level3.com wrote: > > At the risk of belaboring the point, I believe that once the preconditions > have been met in the flow illustrated earlier in the thread (i.e. COMETs > have been exchanged), C has no control over the order of operations; i.e. > whether A or B will connect to the session first. This is true. C cannot control A or B sending 180 and after some time a 200. It is up to A or B. > For at least some > services, telephones being one, it may make sense for C to enforce a > particular order of operations - C may want A to connect to the session > before B. If order of operations is essential to a particular service with > preconditions, then perhaps a similar flow might be constructed in which it > is guaranteed that A will provide a final response before B has the > opportunity to begin alerting. Yes. For some services you will for sure have one party answering before the other one is even alerted. There are so many different services you one think of that it is imposible to define the standard behavior for them. > Moreover, it is not clear to me how 3pcc SIP could guarantee the > simultaneity of final responses from A or B, regardless of preconditions, > for a service such as the camera and storage device that must connect at the > same time. Clearly, A or B simply might not be able to join the session for > reasons unrelated to qos or security. Yes. It might happen that the QoS requirements are fulfil but the party does not want to join the session. > I think the best you can do is choose > one to go first - satisfaction of preconditions is not, as I understand it, > an indication that the entity in question will actually join the session. You are right, but if we think of services where one of the SIP UAs is a machine, not a human, it will respond almost always, excep in failure conditions, with a 200 OK. So, sometimes it might be useful not to wait in order to speed up the set up phase. Anyway, I agree with you that in many situations we will want to wait until one of the parties involved has answered. But again, this should be up to the implementors, I do not believe this is a protocol issue. Regards, Gonzalo > > Jon Peterson > Level(3) Communications > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, July 06, 2000 1:07 AM > To: Peterson, Jon > Cc: jdrosen@dynamicsoft.com; sip@lists.bell-labs.com > Subject: Re: [SIP] QoS & Third Party Call Control in SIP > > Hi, > > Jon.Peterson@Level3.com wrote: > > > > I have a question about the flow below. When C has acquired the > provisional > > media (183) SDP from A, is that the time at which C would like to send an > > INVITE to B? Or would C rather wait until someone actually picks up the > > phone at A? > > The idea is to establish a session between A and B. The presence of C > should be transparent to the user plane. So, C issues the INVITE without > waiting for A to pick up the phone. In fact, A's phone is not ringing, > since the preconditions are not met yet. > > Third party control is useful not just for "telephones". A might be, for > instance, a SIP video camera and B a storage device. We do not want the > storage device to begin recording until the camera begins filming (nor > the other way around)... > > > Jonathan Rosenberg wrote: > > > Well, C can't send an ACK since there is no final response yet. It could > > include the update SDP in the PRACK, in which case you wouldn't need to > > do a re-INVITE. > > I like better the PRACK solution than the re-INVITE approach. PARCKs > would provide a way of updating SDPs from the UAC towards the UAS. In > some situations this is very useful. > > 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 > > _______________________________________________ > 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 07:12:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20501 for ; Fri, 7 Jul 2000 07:12:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B77B44363; Fri, 7 Jul 2000 07:12:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id A08F944336 for ; Fri, 7 Jul 2000 07:12:07 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20482; Fri, 7 Jul 2000 07:12:06 -0400 (EDT) Message-Id: <200007071112.HAA20482@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 07 Jul 2000 07:12:05 -0400 Subject: [SIP] I-D ACTION:draft-deason-sip-soap-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP and SOAP Author(s) : N. Deason Filename : draft-deason-sip-soap-00.txt Pages : 9 Date : 06-Jul-00 This document describes an extension to the Session Initiation Protocol (SIP) [1] . The purpose of this extension is to provide an extremely generic and extensible framework through which SIP nodes can request additional services from remote nodes. Examples of such nodes include SIP Network Servers, SIP User Agents, SIP/PSTN Gateways, SIP/H.323 Gateways and SIP Enabled Application Service Brokers. It also a candidate for providing a remote procedure call mechanism for Call Processing Language (CPL) scripts [2] . This proposal is based upon a new SIP method, called SERVICE. The SERVICE method can carry a Simple Object Access Protocol (SOAP) [3] message as it's payload. SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. SOAP defines a framework for encoding request and response messages in XML. Typically SOAP uses HTTP as a transport protocol but this proposal enables SIP to be used instead. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-deason-sip-soap-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-deason-sip-soap-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-deason-sip-soap-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: <20000706152040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-deason-sip-soap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-deason-sip-soap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706152040.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 Fri Jul 7 07:24:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21068 for ; Fri, 7 Jul 2000 07:24:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 623B344388; Fri, 7 Jul 2000 07:24:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 5078A4435E for ; Fri, 7 Jul 2000 07:24:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21020; Fri, 7 Jul 2000 07:24:03 -0400 (EDT) Message-Id: <200007071124.HAA21020@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 07 Jul 2000 07:24:02 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-03.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : MIME media types for ISUP and QSIG Objects Author(s) : E. Zimmerer, A. Vemuri, L. Ong, M. Zonoun, M. Watson Filename : draft-ietf-sip-isup-mime-03.txt Pages : 6 Date : 06-Jul-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-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-isup-mime-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-isup-mime-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000706152340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-isup-mime-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-isup-mime-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706152340.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 Fri Jul 7 07:27:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21264 for ; Fri, 7 Jul 2000 07:27:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC83144378; Fri, 7 Jul 2000 07:27:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 944D744365 for ; Fri, 7 Jul 2000 07:27:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21187; Fri, 7 Jul 2000 07:27:15 -0400 (EDT) Message-Id: <200007071127.HAA21187@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 07 Jul 2000 07:27:15 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-100rel-02.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --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 : Reliability of Provisional Responses in SIP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-100rel-02.txt Pages : 17 Date : 06-Jul-00 This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag org.ietf.sip.100rel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-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-100rel-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-100rel-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: <20000706152349.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-100rel-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-100rel-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706152349.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 Fri Jul 7 08:04:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22384 for ; Fri, 7 Jul 2000 08:04:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FB2E4435E; Fri, 7 Jul 2000 08:04:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6BBCC44336 for ; Fri, 7 Jul 2000 08:04:08 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id RAA19890 for ; Fri, 7 Jul 2000 17:33:20 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 07 Jul 2000 17:33:18 +0000 (IST) Received: from localhost (srinath@localhost) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id RAA11785 for ; Fri, 7 Jul 2000 17:33:17 +0530 (IST) Date: Fri, 7 Jul 2000 17:33:17 +0530 (IST) From: A Srinath To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Routing of ACK Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, consider the following scenario. ->B | A -> P - | ->C A sends an INVITE to proxy P with (CID=x, CSEQ=1, TO=y, FROM=z) P forks the request to B and C. with appropriate branch tags in VIA. Both B and C respond with 200 OK. which reach A. A finds out about 2 call legs using the tags in the TO field. A sends out 2 ACK's for both the legs with the tags in the TO. It sends both of them to the proxy P. The question is how does P find out where to route the ACK. a. Does it route both the ACK's to both locations. b. Does it maintain the call state to know which tag goes where. Please clarify. regards, Srinath A Silicon Automation Systems Phone: 5276100, 5276108 extn 4220 #1309, 10th Main, HAL III Stage Bangalore 560 008, India _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 08:08:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22587 for ; Fri, 7 Jul 2000 08:08:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB41B44379; Fri, 7 Jul 2000 08:07:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id BC7C644365 for ; Fri, 7 Jul 2000 08:07:35 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id RAA20007 for ; Fri, 7 Jul 2000 17:36:48 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 07 Jul 2000 17:36:47 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id RAA11854 for ; Fri, 7 Jul 2000 17:36:46 +0530 (IST) Message-ID: <054601bfe80b$e10be280$8c40000a@sasi.com> From: "rafi" To: Date: Fri, 7 Jul 2000 17:37:10 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0543_01BFE839.FAA28CC0" 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] on routing logic at proxy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0543_01BFE839.FAA28CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, What all things proxy takes into consideration when it forks a request. I am interested in knowing routing logic. As Rosenberg says "routing logic may=20 have changed (perhaps there was some time of day routing=20 or randomized routing)." in one of his reply. What makes proxy to decide upon selecting particular routing logic for e.g. randomized routing logic. Does routing logic depends on the Method. If yes how exactly. Regards Rafi Assadi H.M. Silicon Automation Systems Bangalore, INDIA=20 ------=_NextPart_000_0543_01BFE839.FAA28CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
     What all things  proxy takes into=20 consideration
when it forks a request. I am interested in knowing
routing logic. As Rosenberg says  "routing logic may
have changed (perhaps there was some time of day routing
or randomized routing)." in one of his reply.  What = makes
proxy to decide upon selecting particular routing logic for = e.g.
randomized routing logic.  Does routing logic depends on = the
Method. If yes how exactly.
 
Regards
Rafi Assadi H.M.
Silicon Automation Systems
Bangalore, INDIA
------=_NextPart_000_0543_01BFE839.FAA28CC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 08:25:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23140 for ; Fri, 7 Jul 2000 08:25:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D194744389; Fri, 7 Jul 2000 08:24:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id A2EFA44336 for ; Fri, 7 Jul 2000 08:24:11 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA23261; Fri, 7 Jul 2000 13:21:40 +0100 (BST) From: "Jo Hornsby" To: "A Srinath" , Subject: RE: [SIP] Routing of ACK Date: Fri, 7 Jul 2000 13:21:40 +0100 Message-ID: <003701bfe80d$e7a25e60$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Hi, > consider the following scenario. > > ->B > | > A -> P - > | > ->C > > A sends an INVITE to proxy P with (CID=x, CSEQ=1, TO=y, FROM=z) > > P forks the request to B and C. with appropriate branch tags in VIA. > > Both B and C respond with 200 OK. which reach A. > > A finds out about 2 call legs using the tags in the TO field. > > A sends out 2 ACK's for both the legs with the tags in the TO. > It sends both of them to the proxy P. > > The question is how does P find out where to route the ACK. > > a. Does it route both the ACK's to both locations. > b. Does it maintain the call state to know which tag goes where. I think the spec is silent on this issue; all it does say is that the proxy should optimise it's routing decisions based on the previous INVITE (I guess if still available) (end of Section 12.4). There's no good reason (that I can think of), however, that the proxy can't be even more optimal by noting the tags seen on branches, and only routing ACKs to the appropriate branches. HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 08: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 ESMTP id IAA23593 for ; Fri, 7 Jul 2000 08:39:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0606344368; Fri, 7 Jul 2000 08:38:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 13DF744336 for ; Fri, 7 Jul 2000 08:38:22 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id NAA27728; Fri, 7 Jul 2000 13:36:18 +0100 (BST) From: "Jo Hornsby" To: "rafi" , Subject: RE: [SIP] on routing logic at proxy Date: Fri, 7 Jul 2000 13:36:17 +0100 Message-ID: <003801bfe80f$f27ac9b0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: <054601bfe80b$e10be280$8c40000a@sasi.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > What all things proxy takes into consideration > when it forks a request. Absolutely anything it likes -- the temperature in Wales, for instance. And as a result, it might not even fork; it might return "500 Proxy Too Cold". > I am interested in knowing > routing logic. As Rosenberg says "routing logic may > have changed (perhaps there was some time of day routing > or randomized routing)." in one of his reply. What makes > proxy to decide upon selecting particular routing logic for e.g. > randomized routing logic. Does routing logic depends on the > Method. If yes how exactly. Routing decisions are where the real power of SIP lies. I guess there's some sort of notion of a "vanilla proxy", which does trivial resolution from the SIP URL in the Request-URI to 0 or more other SIP URLs, perhaps purely as the result of a database lookup, but this is by no means the end of the story. So when it comes down to it, routing logic is way outsida the SIP RFC. Look to some of the drafts available, such as CPL and Caller Preferences, for ideas on typical (routing) services. HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 08: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 ESMTP id IAA24259 for ; Fri, 7 Jul 2000 08:58:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA86844386; Fri, 7 Jul 2000 08:57:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 1BF1444336 for ; Fri, 7 Jul 2000 08:57:37 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id SAA21624; Fri, 7 Jul 2000 18:26:50 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 07 Jul 2000 18:26:48 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id SAA12399; Fri, 7 Jul 2000 18:26:46 +0530 (IST) Message-ID: <05bf01bfe812$dd55b420$8c40000a@sasi.com> From: "rafi" To: "Jo Hornsby" , References: <003801bfe80f$f27ac9b0$4e34c3c1@ubiquity.co.uk> Subject: Re: [SIP] on routing logic at proxy Date: Fri, 7 Jul 2000 18:27:10 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Absolutely anything it likes -- the temperature in Wales, for > instance. And as a result, it might not even fork; it might > return "500 Proxy Too Cold". If routing at proxy is all that independent of the transcation it is carring on then I think it may end up in generating unncessary message into the network. For e.g take the case srinath is talking about. Can proxy act so dump in this such cases ? Thanks Rafi Assadi H.M. ----- Original Message ----- From: Jo Hornsby To: rafi ; Sent: Friday, July 07, 2000 6:06 PM Subject: RE: [SIP] on routing logic at proxy > > What all things proxy takes into consideration > > when it forks a request. > > Absolutely anything it likes -- the temperature in Wales, for > instance. And as a result, it might not even fork; it might > return "500 Proxy Too Cold". > > > I am interested in knowing > > routing logic. As Rosenberg says "routing logic may > > have changed (perhaps there was some time of day routing > > or randomized routing)." in one of his reply. What makes > > proxy to decide upon selecting particular routing logic for e.g. > > randomized routing logic. Does routing logic depends on the > > Method. If yes how exactly. > > Routing decisions are where the real power of SIP lies. I > guess there's some sort of notion of a "vanilla proxy", which > does trivial resolution from the SIP URL in the Request-URI to > 0 or more other SIP URLs, perhaps purely as the result of a > database lookup, but this is by no means the end of the story. > > So when it comes down to it, routing logic is way outsida the > SIP RFC. Look to some of the drafts available, such as CPL and > Caller Preferences, for ideas on typical (routing) services. > > HTH, > > > - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 09:58:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26392 for ; Fri, 7 Jul 2000 09:58:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0170044386; Fri, 7 Jul 2000 09:57:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id B42FE44336 for ; Fri, 7 Jul 2000 09:57:46 -0400 (EDT) Received: (qmail 5837 invoked by uid 1002); 7 Jul 2000 13:56:40 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14693.57752.153369.453619@jodie.lucid> Date: Fri, 7 Jul 2000 16:56:40 +0300 (IDT) To: SIP Subject: Re: [SIP] Proxy replies to BYE In-Reply-To: <3964B5C2.6C9FA144@dynamicsoft.com> References: <14692.44660.572998.305448@jodie.lucid> <3964B5C2.6C9FA144@dynamicsoft.com> X-Mailer: VM 6.62 under Emacs 19.34.1 Reply-To: Dvir Oren Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes ("Re: [SIP] Proxy replies to BYE"): > No, this is correct in the end to end model, which is what we have here. > As BYE responses are generally automatic, you won't usually see even a > single BYE retransmission, since the response will come within 4 seconds > (the 100 Trying from each proxy will cause the BYE retransmission rate > to increase to 4 seconds). Even if the responses are automatic, if the request has to travel a long distance (whether it is many proxies, or many routers, or both), the response might take some time. It also might take some time if one of the servers along the way is a bit busy. As far as I understand it, 4 seconds is a lot of time. If the second bye is sent after 30sec, and then after 1sec, and then after 2sec, then 4 BYEs will be sent at the end client. Each proxy along the way will send less and less as the OK will reach it sooner. It seems to me like the protocol assumes, or expects the call to stop going through a proxy after the OK. This might be good in many cases, but it limits certain applications. This is why the Record-Route header was 'invented'. However, the behavior of the proxy does not suit, IMHO, the situation above. I don't understand why BYE has to be end-to-end. If I hang up my telephone, as much as I want the other end to hang up his telephone, I really couldn't care less if there was some problem along the way. Perhaps the solution is simply for the proxy to send a 100 'Trying' response to quiet down the client. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 10:08:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26871 for ; Fri, 7 Jul 2000 10:08:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C74D44391; Fri, 7 Jul 2000 10:07:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id A0B9C4437C for ; Fri, 7 Jul 2000 10:07:28 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA29739; Fri, 7 Jul 2000 10:07:27 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA13104; Fri, 7 Jul 2000 10:07:26 -0400 (EDT) Message-ID: <3965E41E.B925C083@cs.columbia.edu> Date: Fri, 07 Jul 2000 10:07:26 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rajeev@empowertel.com Cc: "'Henry Sinnreich'" , sip@lists.bell-labs.com Subject: Re: Softswitches (was Re: [SIP] SIP->XML->SOAP) References: <006e01bfe7cd$30e3a340$276fa8c0@empowertel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rajeev Gupta wrote: > > 2) You have the choice today to run your SIP UA on your desktop connected to > your ISP, and thus talk to any SIP server of your choice. Similarly, you > could connect your GCP phone or IAD to any MGC that will talk to you. The > protocol model (SIP vs GCP) does not imply a business model (open/free vs > controlled/fee). Not quite. While you can have as many SIP identifiers you want (implying that you can get services and calls from as many companies as you like), your phone can only be controlled by one MGC at a time. (You can obviously switch to another one, but then you can't receive calls through the former one any more.) -- 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 Jul 7 10:38:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27879 for ; Fri, 7 Jul 2000 10:38:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F173044380; Fri, 7 Jul 2000 10:37:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 7851444336 for ; Fri, 7 Jul 2000 10:37:54 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jul 2000 07:38:16 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Gethin Liddell'" Cc: sip@lists.bell-labs.com, Henning Schulzrinne , "'Jonathan Rosenberg'" Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Fri, 7 Jul 2000 07:38:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Gethin, > I do see problems with the new method you suggested. For example, the > suggested characters & and $ are valid in their own right in the tel > url (unless i've read it wrong again :) ) so we would need to > translate > or do something with all occurances of them. The same problem occurs > with `/' being used in the longer escaped string. The & and $ are reserved characters (RFC2396) in the tel: private prefix and future extension paramter names and values (therefore must be quoted if they appear in these fields) _and_ they are not used in the tel: syntax as meta-characters (as far as I can see). Therefore, these two characters should never appear in a tel:. The two characters are also unreserved in the sip: user part(ie don't have to be escaped). [Forget about the '/' character - I was looking at the wrong unreserved list for that one.] John Rosenburg says this merely cascades the problem - I disagree. There is a difference between escaping the tel: URL and merely escaping the whole sip: URL. In the former case the user part is an actually an interpreted/embedded field, not just an opaque string (as would be the case if someone was to escape the URL). For instance, if someone else was to escape the whole sip URL [per RFC2396] _without_ recursively escaping the URL how would you tell whether sip:host%3bparameter=value%3bhidden referred to a parameter with value "value;hiddden" or is "hidden" a separate parameter? So my point is: if you don't do recursive escaping of the SIP URL then the telephone-suscriber part is the least of your worries (and if you do recursive escaping then this doesn't cause a problem). So I don't see how this cascades the problem. Cheers, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 10:45:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28119 for ; Fri, 7 Jul 2000 10:45:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E6F2A44392; Fri, 7 Jul 2000 10:44:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id EB8E444336 for ; Fri, 7 Jul 2000 10:44:18 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA01112; Fri, 7 Jul 2000 10:44:15 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA13923; Fri, 7 Jul 2000 10:44:15 -0400 (EDT) Message-ID: <3965ECBE.AE469204@cs.columbia.edu> Date: Fri, 07 Jul 2000 10:44:14 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'Gethin Liddell'" , sip@lists.bell-labs.com, "'Jonathan Rosenberg'" Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Frankly, I thought we solved this problem already several days ago? Why invent a kludge that no other URL scheme is using to solve a non-issue? -- 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 Jul 7 11: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 ESMTP id LAA28764 for ; Fri, 7 Jul 2000 11:04:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 809A244395; Fri, 7 Jul 2000 11:03:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 88A2144336 for ; Fri, 7 Jul 2000 11:03:07 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA17498; Fri, 7 Jul 2000 11:04:26 -0400 (EDT) Message-ID: <3965F1C3.C553E9C1@dynamicsoft.com> Date: Fri, 07 Jul 2000 11:05:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rafi Cc: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] on routing logic at proxy References: <003801bfe80f$f27ac9b0$4e34c3c1@ubiquity.co.uk> <05bf01bfe812$dd55b420$8c40000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit rafi wrote: > > > Absolutely anything it likes -- the temperature in Wales, for > > instance. And as a result, it might not even fork; it might > > return "500 Proxy Too Cold". > > If routing at proxy is all that independent of > the transcation it is carring on then I think it may > end up in generating unncessary message into > the network. For e.g take the case srinath is > talking about. Can proxy act so dump in this such cases ? If the proxy is routing "dumbly", I suggest you buy someone elses. Routing is the core function of a proxy. As Jo has said, it can be done in many ways besides the simple request URI based mechanisms formally specified. How it is done, and in what ways it can be controlled, is at the core of building proxy applications. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 11:08:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28952 for ; Fri, 7 Jul 2000 11:08:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 482794439F; Fri, 7 Jul 2000 11:08:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7D17444336 for ; Fri, 7 Jul 2000 11:08:09 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA17570; Fri, 7 Jul 2000 11:09:33 -0400 (EDT) Message-ID: <3965F2F7.EDB425D5@dynamicsoft.com> Date: Fri, 07 Jul 2000 11:10:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Cc: SIP Subject: Re: [SIP] Proxy replies to BYE References: <14692.44660.572998.305448@jodie.lucid> <3964B5C2.6C9FA144@dynamicsoft.com> <14693.57752.153369.453619@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir Oren wrote: > > Jonathan Rosenberg writes ("Re: [SIP] Proxy replies to BYE"): > > > No, this is correct in the end to end model, which is what we have here. > > As BYE responses are generally automatic, you won't usually see even a > > single BYE retransmission, since the response will come within 4 seconds > > (the 100 Trying from each proxy will cause the BYE retransmission rate > > to increase to 4 seconds). > > Even if the responses are automatic, if the request has to travel a long > distance (whether it is many proxies, or many routers, or both), the > response might take some time. It also might take some time if one > of the servers along the way is a bit busy. > > As far as I understand it, 4 seconds is a lot of time. If the second bye > is sent after 30sec, and then after 1sec, and then after 2sec, then 4 > BYEs will be sent at the end client. Each proxy along the way will > send less and less as the OK will reach it sooner. You have missed my point. Each proxy receiving the BYE will send a 100 Trying. This causes the BYE retransmissions to immediately become 4 seconds. Thus, so long as you get a final response to the request within 4 seconds (a long time by your own reckoning) there will be no extra retransmissions. The spec is clear on this one: Section 7.1: > Informational responses indicate that the server or proxy contacted > is performing some further action and does not yet have a definitive > response. The client SHOULD wait for a further response from the > server, and the server SHOULD send such a response without further > prompting. A server SHOULD send a 1xx response if it expects to take > more than 200 ms to obtain a final response. Note the last sentence. > > It seems to me like the protocol assumes, or expects the call to > stop going through a proxy after the OK. Umm, no. > This might be good > in many cases, but it limits certain applications. This is why > the Record-Route header was 'invented'. However, the behavior > of the proxy does not suit, IMHO, the situation above. That is because you have misunderstood the reliability mechanism. > > I don't understand why BYE has to be end-to-end. If I hang > up my telephone, as much as I want the other end to hang up > his telephone, I really couldn't care less if there was some > problem along the way. What your UI presents to the user, and reliability mechanisms in the protocol, are separate issues. > > Perhaps the solution is simply for the proxy to send a > 100 'Trying' response to quiet down the client. It will. Thats what I am saying. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 11:13:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29192 for ; Fri, 7 Jul 2000 11:13:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56DD3443AD; Fri, 7 Jul 2000 11:13:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 98F8144336 for ; Fri, 7 Jul 2000 11:13:14 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA13784; Fri, 7 Jul 2000 16:10:30 +0100 (BST) From: "Jo Hornsby" To: "A Srinath" , Subject: RE: [SIP] Differant URL's in headers Date: Fri, 7 Jul 2000 16:10:30 +0100 Message-ID: <003c01bfe825$7d236990$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I have a query regarding URLs of other schemes in the headers. > > 1. How does a user agent client send an INVITE to a TO conatianing, > say a mailto URL or even an HTTP URL. What will be the Request-URI > then. Well, I would typically expect the Request-URI to (initially) be the same as the To, as specified by Section 11.1. However, I think it is reasonable to say that for schemes such as mailto:, the intent is not obvious -- are you intending to set up a mail session; what does this mean? In the end, it's going to require User Agents that understand the semantics of these non-SIP URL URIs, and perhaps any proxies along the path to understand, too (proxies are required to return 400 if they don't understand the scheme in the Request-URI). If you want "normal" SIP-routing on an unknown SIP "network" with a non-SIP URI, then the UAs/edge-proxies are going to have to do something clever like encoding the "real" Request-URI into a SIP URL-compatible form, or perhaps just rely on the To being honoured (completely reasonable for a UAS), and set the Request-URI to some sort of "pseudo" SIP URL that will make it likely the Request gets to the right place. I think section 4.3 (in the bis) has the best explanation of typical behaviour; of course, once outsida SIP URLs, things are a little more atypical. 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 Jul 7 11:15:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29242 for ; Fri, 7 Jul 2000 11:15:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C15CC443B5; Fri, 7 Jul 2000 11:13:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cedar.dcs.shef.ac.uk (cedar.dcs.shef.ac.uk [143.167.8.6]) by lists.bell-labs.com (Postfix) with ESMTP id 771C544336 for ; Fri, 7 Jul 2000 11:13:27 -0400 (EDT) Received: from borg (borg.dcs.shef.ac.uk [143.167.11.44]) by cedar.dcs.shef.ac.uk (8.9.3+Sun/8.9.3) with SMTP id QAA10347; Fri, 7 Jul 2000 16:06:42 +0100 (BST) Message-ID: <026401bfe825$a6891960$2c0ba78f@dcs.shef.ac.uk> From: "Chern Nam Yap" To: "MIP List" Date: Fri, 7 Jul 2000 16:08:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [SIP] Re: why IIP? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Even though IIP is not meant to solve every problem, but IIP trying to resolve what Mobile IP can't resolve currently. Such as 1) Trianglar routing For MIPv4 is still stuck with Triangluar routing and Reverse Tunnelling. 2) Signalling Traffic, Current mobility protocols generate too much traffic and low reliability. 3) Topology Complexity for fast hand off for IPv4 and IPv6, Hierarchical model is far too complex just to solve handoff problem. 4) Mobility transition between IPv4 and IPv6. Any node meant for MIPv4 would not work in MIPv6 environment, via visa. Cheers ---------------------------------------------------------------------------- --- Chern Nam Yap Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield Regent Court 211 Portobello Street Sheffield S1 4DP United Kingdom Tel:+44 (0) 114-222-3308 Fax:+44 (0) 114-222-8299 Web: www.mobile1.net E-mail: cny@dcs.shef.ac.uk E-mail: cny@ieee.org > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 11:32:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29809 for ; Fri, 7 Jul 2000 11:32:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A9A8A443A8; Fri, 7 Jul 2000 11:31:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 040BA44395 for ; Fri, 7 Jul 2000 11:31:47 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA17986; Fri, 7 Jul 2000 11:33:00 -0400 (EDT) Message-ID: <3965F7CD.3FFD9914@dynamicsoft.com> Date: Fri, 07 Jul 2000 11:31:25 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Henning Schulzrinne , vkg@lucent.com, "Vakil, Mohammad" , Dvir Oren , SIP Subject: Re: [SIP] OK with no ACK References: <91522176F94CD4119FAB00B0D0492B4312AC87@ORT-EXCH> <3964A355.4535A9C7@dynamicsoft.com> <3964E42F.28820A03@lucent.com> <3964E942.6F03ED41@cs.columbia.edu> <396558E4.98C35081@dynamicsoft.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Henning Schulzrinne wrote: > > > > "Vijay K. Gurbani" wrote: > > > > > > > > > RFC indicates that a BYE is just as appropriate. Should we finalize on > > > one of CANCEL or BYE in cases like this? Or is it too much trouble to > > > codify such cases and prescribe behavior? > > > > > If the caller wants to hang up a call, but hasn't yet received a final > response, it can send a CANCEL or a BYE. It can also send both CANCEL and BYE to get the best of both worlds. Note that this takes nearly no extra time since you can send BYE right after CANCEL. I don't really see the problem with having this behavior dependent on the state: the state has to be maintained anyway, right? And I don't think that an extra "if" statement complicates things all that much. 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 Fri Jul 7 11:50:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00487 for ; Fri, 7 Jul 2000 11:50:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFECD443A5; Fri, 7 Jul 2000 11:49:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by lists.bell-labs.com (Postfix) with ESMTP id 1B34C44336 for ; Fri, 7 Jul 2000 11:49:52 -0400 (EDT) Received: from indigosw.com (uu212-190-94-130.unknown.uunet.be [212.190.94.130]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id IAA29441 for ; Fri, 7 Jul 2000 08:49:19 -0700 (PDT) Message-ID: <3965FCE3.86E1CD04@indigosw.com> Date: Fri, 07 Jul 2000 17:53:07 +0200 From: dENIS Vandersteene Organization: Indigo Software X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Content-Length header and End-to-End Encryption Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi there, In RFC 2543bis (July) Section 13.1.1 (End-to-End Encryption) and Table 4 & 5 (on pages 35-36) mention what headers MUST NOT be encrypted and what headers MAY be. Referring to Table 4, the Content-Length header MAY be encrypted, but in section 13.1.1, § 2 on page 88, it is said : " Upon receipt by the called UA possessing the correct decryption key, the message body as indicated by the Content-Length field is decrypted, [...]" So, shouldn't that be a "MUST NOT be encrypted" header, as it's needed to decrypt the message? Thanks, dENIS -- Denis Vandersteene Software Engineer Indigo Software 50 Rue Wiertz Brussels, 1050 – Belgium Tel. +32 2 401 68 23 denis@indigosw.com http://www.indigosw.com -------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 11:55:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00796 for ; Fri, 7 Jul 2000 11:55:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01AA3443BD; Fri, 7 Jul 2000 11:55:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 74775443AD for ; Fri, 7 Jul 2000 11:54:56 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA04307; Fri, 7 Jul 2000 11:54:55 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA15714; Fri, 7 Jul 2000 11:54:55 -0400 (EDT) Message-ID: <3965FD4F.8C183AE7@cs.columbia.edu> Date: Fri, 07 Jul 2000 11:54:55 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: dENIS Vandersteene Cc: sip Subject: Re: [SIP] Content-Length header and End-to-End Encryption References: <3965FCE3.86E1CD04@indigosw.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 8bit dENIS Vandersteene wrote: > > Hi there, > > In RFC 2543bis (July) Section 13.1.1 (End-to-End Encryption) and Table 4 > & 5 (on pages 35-36) mention what headers MUST NOT be encrypted and what > headers MAY be. Referring to Table 4, the Content-Length header MAY be > encrypted, but in section 13.1.1, § 2 on page 88, it is said : > " Upon receipt by the called UA possessing the correct decryption > key, the message body as indicated by the Content-Length field is > decrypted, [...]" > > So, shouldn't that be a "MUST NOT be encrypted" header, as it's needed > to decrypt the message? > I don't see Content-Length as sensitive, so it probably should not be encrypted. I changed the table entry. -- 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 Jul 7 12:13:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01572 for ; Fri, 7 Jul 2000 12:13:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0EA24443B2; Fri, 7 Jul 2000 12:12:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id A58EF44395 for ; Fri, 7 Jul 2000 12:12:29 -0400 (EDT) Received: from cisco.com (localhost [127.0.0.1]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id MAA21746 for ; Fri, 7 Jul 2000 12:12:15 -0400 (EDT) Message-ID: <3966015F.88D8D11A@cisco.com> Date: Fri, 07 Jul 2000 12:12:15 -0400 From: Sudipto Mukherjee Organization: Cisco X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] QoS and Mid-Session SDP changes Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, RE-INVITEs can change media characteristics such as port, IP address and codecs, for QoS-Assured Sessions. In this case, resource reservation needs to be done again with the new media parameters for the ongoing session. The following flow illustrates the above scenario - A B <-- Active Session with Qos ----> A decides to change media characteristics and sends a Re-INVITE. INV (New SDP A w precondition) ---------------------------------> 183 (SDP B w precondition) <-------------------------------- PRACK --------------------------------> 200 OK (PRACK) <------------------------------- Reservations successful at A & B COMET ---------------------------------> 200 OK (COMET) <-------------------------------- COMET <-------------------------------- 200 OK (COMET) ---------------------------------> 200 OK (SDP B) <-------------------------------- ACK ---------------------------------> Session resumes with updated media parameters The above flow generates lots of signaling traffic for a mid-call SDP change. Please comment on the correctness of the flow. Any suggestions to improve upon, is appreciated. Thanks -- Sudipto --------------------------------------------------------------------------- Sudipto Mukherjee Cisco Systems, Inc sudiptom@cisco.com 7025 Kit Creek Rd 919-392-5780 PO Box 14987 Research Triangle Park, NC 27709 -------------------------------------------------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 12:55:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03707 for ; Fri, 7 Jul 2000 12:55:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D526644379; Fri, 7 Jul 2000 12:55:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 8715344336 for ; Fri, 7 Jul 2000 12:55:28 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id MAA28231; Fri, 7 Jul 2000 12:55:25 -0400 (EDT) Message-ID: <054001bfe834$a32a1210$3102a8c0@broadsoft.com> From: "Brett Tate" To: "Igor Slepchin" Cc: "SIPbell-labs" References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis Date: Fri, 7 Jul 2000 12:58:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Igor Slepchin To: Brett Tate Cc: SIPbell-labs Sent: Thursday, July 06, 2000 8:45 PM Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis > > Brett Tate wrote: > > It > > would be worth mentioning in this section that a media > > stream can also be deleted by the absence of a "m=..." > > line which was in the previous SDP for the call leg. > > This is wrong: it cannot. The m= lines are never removed, otherwise you > wouldn't be able to match m lines in response and request. Consider a > situation where the request contains > > c=IN IP4 1.2.3.4 > m=audio 54678 RTP/AVP 0 1 3 > m=video 7346 RTP/AVP 10 13 (face) > m=video 7880 RTP/AVP 10 11 (presentation) > > If the response contained something like > m=audio 6540 RTP/AVP 0 1 > m=video 6578 RTP/AVP 10 > > there would be no way to tell which of the two offered media streams was > accepted and which one rejected. > Thanks for the response. Let me clarify my comment/question a little more concerning section B.5. After having went through the INVITE/200/ACK process to set up a call-leg, why does the re-INVITE need to keep passing around "m=" lines that are now considered to be just place holders? The restriction of requiring the old "m=" lines to be passed in a re-INVITE, adds unnecessary restrictions on 3rd party call controllers (3pcc). A---A's(3pcc)----B | C For example, A and B are talking, and A has a 3rd party call controller. When a new call arrives at A's 3pcc from C, the 3pcc should be able to just perform a re-INVITE to allow A to communicate with C. However because of the restriction, the 3pcc would be forced to either insert the no longer used "m=" place holders into the SDP or use a transfer mechanism instead. > > It might also be worth mentioning somewhere in > > Appendix B that receiving a completely new SDP within > > a call-leg should render the previous SDP obsolete. > > See above. There is currently no way to completely replace SDP, you can > only update it either by rejecting some media sessions (by setting their > port # to 0) or by adding the new ones at the end of the list. See above comments and questions. > > 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 Fri Jul 7 13:08:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04629 for ; Fri, 7 Jul 2000 13:08:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E750443BD; Fri, 7 Jul 2000 13:06:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 80082443A8 for ; Fri, 7 Jul 2000 13:06:36 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA07605; Fri, 7 Jul 2000 13:06:35 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA17868; Fri, 7 Jul 2000 13:06:34 -0400 (EDT) Message-ID: <39660E1A.7F16F52C@cs.columbia.edu> Date: Fri, 07 Jul 2000 13:06:34 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Brett Tate , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > > Brett Tate wrote: > > It > > would be worth mentioning in this section that a media > > stream can also be deleted by the absence of a "m=..." > > line which was in the previous SDP for the call leg. > > This is wrong: it cannot. The m= lines are never removed, otherwise you > wouldn't be able to match m lines in response and request. Consider a > situation where the request contains > > c=IN IP4 1.2.3.4 > m=audio 54678 RTP/AVP 0 1 3 > m=video 7346 RTP/AVP 10 13 (face) > m=video 7880 RTP/AVP 10 11 (presentation) > > If the response contained something like > m=audio 6540 RTP/AVP 0 1 > m=video 6578 RTP/AVP 10 > > there would be no way to tell which of the two offered media streams was > accepted and which one rejected. While I don't disagree, practically speaking this multiple-instance-of-one-type situation is fairly uncommon. We probably still need to define what happens if you get a new SDP (it replaces the old one). Realistically, we can't expect that m=audio 4321 ... m=video 5678 ... will be answered by m=audio 8888 ... m=video 0 I suspect most implementations simply reply m=audio 8888 if they can't do video. I think there was some discussion at some point of labeling streams in SDP, which would simplify this. (http://www.ietf.org/internet-drafts/draft-camarillo-sip-sdp-00.txt seems to solve the opposite problem of "splitting" a single logical stream across ports, but maybe the two concepts can be married.) > > > It might also be worth mentioning somewhere in > > Appendix B that receiving a completely new SDP within > > a call-leg should render the previous SDP obsolete. > > See above. There is currently no way to completely replace SDP, you can > only update it either by rejecting some media sessions (by setting their > port # to 0) or by adding the new ones at the end of the list. > > Thank you, > Igor Slepchin > > _______________________________________________ > 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 Fri Jul 7 14:04:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07892 for ; Fri, 7 Jul 2000 14:04:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8F4744395; Fri, 7 Jul 2000 14:04:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 77FFC44336 for ; Fri, 7 Jul 2000 14:04:09 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA10205 for ; Fri, 7 Jul 2000 14:04:07 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA20620 for ; Fri, 7 Jul 2000 14:04:06 -0400 (EDT) Message-ID: <39661B96.88B001E4@cs.columbia.edu> Date: Fri, 07 Jul 2000 14:04:06 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] New SIP FAQ Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin, Jonathan Rosenberg and I updated the SIP FAQ. It now uses the Faq-O-Matic tool that will hopefully simplify maintaining it without the bottleneck of a single "editor". See http://www.cs.columbia.edu/~hgs/sip/faq.cgi The old FAQ is still available for now. Comments and suggestions are most appreciated. Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 14:13:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08278 for ; Fri, 7 Jul 2000 14:13:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06D07443A8; Fri, 7 Jul 2000 14:13:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 892A84439B for ; Fri, 7 Jul 2000 14:13:27 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA19462; Fri, 7 Jul 2000 14:14:38 -0400 (EDT) Message-ID: <39661DAF.34044F4E@dynamicsoft.com> Date: Fri, 07 Jul 2000 14:13:03 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Henning Schulzrinne Cc: Brett Tate , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The problem with replacing SDP is that the replacement is impossible to detect generally. Say, I want to replace one media steam with another one with the same set of codecs. There is no way to do this unless you can match media lines in the new and old media descriptions. Mandating the order is one way to do this and that's how it is supposed to be done according to the RFC. Generally, I see no harm caused by including "m=" lines with 0 ports. It is probably OK to be forgiving about receiving SDP with missing media lines if there is no ambiguity, but it is _not_ OK to generate such SDPs. In the example Henning cited, what happens if the callee later issues a re-INVITE with m=audio 8888 ... m=video 4444 ... Did the callee accept the original media stream or offered a new one? Besides, this clearly wouldn't work if all m= lines specified audio. So why create special cases if everything is already handled by the generic rules? Using the stream labeling was proposed on this list before and it works but gives no clear advantages I can think of. Besides, to be backwards compatible (i.e., if one of the parties doesn't support the extension) you have to be able to go back to the current algorithm so every implementation would need to support both anyway. BTW, note that draft-camarillo-sip-sdp-00.txt doesn't really solve the problem it poses, namely splitting the same media stream across multiple destination ports based on the codec type. SDP is the least of the problems here. The real issue is that doing this split will break RTP: real-time characteristics of RTP are almost lost since now there is now way to detect (and recover from) packet loss, hence there is no good way to adapt playout buffers; RTCP is broken so there is no way to dynamically adapt to changing network conditions, and, finally, no compliant RTP library will allow you change destination of the RTP stream by changing the payload type of RTP packets. All of this was discussed on the list, and the draft (somewhat surprisingly to me) references that discussion. Thank you, Igor Slepchin Henning Schulzrinne wrote: > <...> > Realistically, we can't expect that > > m=audio 4321 ... > m=video 5678 ... > > will be answered by > > m=audio 8888 ... > m=video 0 > > I suspect most implementations simply reply > > m=audio 8888 > > if they can't do video. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 15:51:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11517 for ; Fri, 7 Jul 2000 15:51:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E82A44438D; Fri, 7 Jul 2000 15:51:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id E0E3A44336 for ; Fri, 7 Jul 2000 15:51:26 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id PAA55458; Fri, 7 Jul 2000 15:51:25 -0400 (EDT) Message-ID: <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> From: "Brett Tate" To: "Igor Slepchin" , "Henning Schulzrinne" Cc: "SIPbell-labs" References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis Date: Fri, 7 Jul 2000 15:54:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Igor Slepchin To: Henning Schulzrinne Cc: Brett Tate ; SIPbell-labs Sent: Friday, July 07, 2000 2:13 PM Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis > The problem with replacing SDP is that the replacement is impossible to > detect generally. Say, I want to replace one media steam with another > one with the same set of codecs. There is no way to do this unless you > can match media lines in the new and old media descriptions. Mandating > the order is one way to do this and that's how it is supposed to be done > according to the RFC. What's wrong with allowing a re-INVITE with a new "o=" (or maybe the same "o=") to indicate that all previous SDP information is obsolete? I think that this would greatly increase the flexibility of 3rd party call controllers. It would also make it easier to attach a SIP stack to end points which already generate complete non-SIP specific SDPs. It also reduces the overhead of having to continually store and pass around "m=" lines with 0 ports in re-INVITEs. > > Generally, I see no harm caused by including "m=" lines with 0 ports. It > is probably OK to be forgiving about receiving SDP with missing media > lines if there is no ambiguity, but it is _not_ OK to generate such > SDPs. In the example Henning cited, what happens if the callee later > issues a re-INVITE with > > m=audio 8888 ... > m=video 4444 ... > > Did the callee accept the original media stream or offered a new one? > Besides, this clearly wouldn't work if all m= lines specified audio. So > why create special cases if everything is already handled by the generic > rules? I can see potential uses for adding the "m=" lines with 0 ports within 200 responses or "Delayed Media" ACKs; however I'm not sure the benefits outweigh the restriction of forcing the use of a "SIP specific" SDP. What are the benefits of using the "m=" with port 0 in a re-INVITE? > > Using the stream labeling was proposed on this list before and it works > but gives no clear advantages I can think of. Besides, to be backwards > compatible (i.e., if one of the parties doesn't support the extension) > you have to be able to go back to the current algorithm so every > implementation would need to support both anyway. > > BTW, note that draft-camarillo-sip-sdp-00.txt doesn't really solve the > problem it poses, namely splitting the same media stream across multiple > destination ports based on the codec type. SDP is the least of the > problems here. The real issue is that doing this split will break RTP: > real-time characteristics of RTP are almost lost since now there is now > way to detect (and recover from) packet loss, hence there is no good way > to adapt playout buffers; RTCP is broken so there is no way to > dynamically adapt to changing network conditions, and, finally, no > compliant RTP library will allow you change destination of the RTP > stream by changing the payload type of RTP packets. All of this was > discussed on the list, and the draft (somewhat surprisingly to me) > references that discussion. > > Thank you, > Igor Slepchin > > > Henning Schulzrinne wrote: > > <...> > > Realistically, we can't expect that > > > > m=audio 4321 ... > > m=video 5678 ... > > > > will be answered by > > > > m=audio 8888 ... > > m=video 0 > > > > I suspect most implementations simply reply > > > > m=audio 8888 > > > > if they can't do video. > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 7 16: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 ESMTP id QAA12280 for ; Fri, 7 Jul 2000 16:22:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8DC4443BF; Fri, 7 Jul 2000 16:21:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 04D7344336 for ; Fri, 7 Jul 2000 16:21:30 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FXC00L01GJJJ2@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 7 Jul 2000 20:21:19 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FXC00EPSGJIS4@firewall.mcit.com>; Fri, 07 Jul 2000 20:21:19 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) id <0FXC00G01GFHLY@dgismtp01.wcomnet.com>; Fri, 07 Jul 2000 20:21:18 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FXC00G01GFCKX@dgismtp01.wcomnet.com>; Fri, 07 Jul 2000 20:18:52 +0000 (GMT) Received: from C25776A ([166.35.248.138]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FXC00EBIGF1BR@dgismtp01.wcomnet.com>; Fri, 07 Jul 2000 20:18:39 +0000 (GMT) Date: Fri, 07 Jul 2000 15:18:32 -0500 From: Henry Sinnreich Subject: RE: [SIP] authentication at gateway In-reply-to: To: "Culpepper, Bert" , "Gardell, Steve" , "'Jonathan Rosenberg'" , Serban Tatu Cc: siplist Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit A SIP "only" (non >MGCP/Megago specific) solution >for PSTN-phone event detection and reporting (as has >also been proposed) >would allow the service to be agnostic to the endpoint >type but may not map >to MGCP and Megaco. There are several reasons why the service has to be agnostic of the type of client. Such as for 1. the ease of introduction of new services and 2. any to any communications. Client specific knowledge, such as MGCP inside is IMHO a very bad architecture. Henry >-----Original Message----- >From: Culpepper, Bert >[mailto:bert.culpepper@intervoice-brite.com] >Sent: Wednesday, July 05, 2000 9:46 PM >To: Henry Sinnreich; Gardell, Steve; 'Jonathan >Rosenberg'; Serban Tatu >Cc: siplist >Subject: RE: [SIP] authentication at gateway > > >My study of gateway capabilities has not revealed an >answer to Serban's >question other than that authentication (via the >scenarios described) is not >available in gateways today and is not likely to show >up anytime soon if at >all. IMO, the most likely solution is very much like >#3 for the scenario >given. An MCGP or Megaco compliant gateway can >collect and report DTMF >digits in signaling separate from the media. However, >this requires the SIP >UAS to also "speak" one of these protocols (obviously, >not a good solution >at all). In networks where PSTN phones are served >there is also likely to >be a Gateway Controller that provides an interface >between the gateway and >SIP UA. A practical and feasible approach is to >extend the gateway's >MGCP/Megaco-based event detection and reporting to SIP >UAs (for which at >least one solution has been proposed). The >application-specific prompts can >be provided by the application server and leave the >gateway to performing >its "gateway" functions. A SIP "only" (non >MGCP/Megago specific) solution >for PSTN-phone event detection and reporting (as has >also been proposed) >would allow the service to be agnostic to the endpoint >type but may not map >to MGCP and Megaco. > >Maybe we'll see a solution in the near future for all >terminals (SIP, PSTN, >others?). > >Bert > >-----Original Message----- >From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com] >Sent: Wednesday, July 05, 2000 6:02 PM >To: Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu >Cc: siplist >Subject: RE: [SIP] authentication at gateway > > >>I suggest that the appropriate >>"converged" >>architecture is to have authentication controlled from outside >>the gateway and to implement it via a SIP Proxy(like?) >>element in >>situations where we want the core service to be >>agnostic as to whether >>the endpoint is a gateway or a UA. > >Exactly right! > >Henry > >>-----Original Message----- >>From: sip-admin@lists.bell-labs.com >>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >>Gardell, Steve >>Sent: Wednesday, July 05, 2000 6:42 AM >>To: 'Jonathan Rosenberg'; Serban Tatu >>Cc: siplist >>Subject: RE: [SIP] authentication at gateway >> >> >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>> Sent: Wednesday, July 05, 2000 12:01 AM >>> To: Serban Tatu >>> Cc: siplist >>> Subject: Re: [SIP] authentication at gateway >>> >>> >>> THe most likely scenario is one you left out: the >>prompting and >>> collection for the PIN are all performed by the originating >>> gateway. In >>> general, the entity demanding authentication will >>not know that the >>> request is through a gateway. I believe its unlikely >>the entity would >>> return 200 OK, or even a 401 with content. Rather, >>just a 401. >>> >>> So, upon receiving the 401, the gateway performs some local >>> operation to >>> get the username and password. Perhaps it plays out an >>> announcement and >>> collects the username/password; perhaps they are >>simply established >>> ahead of time and stored in a database - the gateway >>just fetches them >>> when prompted for authentication. >>> >> >> >>A practical issue with this approach is that gateways >are often >>deployed in support of many different services that may have >>different authentication requirements. Placing all of the >>authentication smarts in the gateway makes it >difficult to roll >>out new services. Now admittedly this is a "telco >centric" view >>of the service world - I suggest that the appropriate >>"converged" >>architecture is to have authentication controlled from outside >>the gateway and to implement it via a SIP Proxy(like?) >>element in >>situations where we want the core service to be >>agnostic as to whether >>the endpoint is a gateway or a UA. >> >> >>> -Jonathan R. >>> >>> Serban Tatu wrote: >>> > >>> > Hi, >>> > >>> > How is authentication performed by a SIP-enabled gateway? >>> Let's say somebody on >>> > a PSTN phone wants to gain access to a service and >>> therefore has to provide a >>> > username/password. Some scenarios come to mind >>(newbie >>> > here): >>> > >>> > Scenario 1 (smart gateway): >>> > >>> > - SIP UAS at service side sends a 401 unauthorized as a >>> response to the INVITE. >>> > The response contains a voice prompt audio file (e.g. >>> Gimme >>> > username/password). >>> > - gateway is so smart that it knows how to play the prompt >>> and collect DTMF >>> > tones representing username and password, which it then >>> sends back encoded >>> > somehow to the service. >>> > >>> > Scenario 2 (not so smart gateway): >>> > >>> > - SIP UAS at service side sends back a 200 OK response to >>> the INVITE. The >>> > response contains the voice prompt as before. >>> > - gateway knows how to play the audio file, sends ACK, >>> media connections are >>> > open. >>> > - SIP UAS at service side then sends an INFO >>message with a >>> DTMF collection >>> > scheme (voice prompt could also be sent here). >>> > - gateway collects the tones and sends them back with >>> another INFO message. >>> > >>> > Scenario 3 (dumb gateway): >>> > >>> > - SIP UAS at service side sends back a 200 OK response to >>> the INVITE. >>> > - gateway and SIP UAS establish their media channels. >>> > - service then plays the whole authentication scenario >>> through the media >>> > channels. Gateway lets DTMF tones flow through the >>media path. >>> > >>> > Do any of these scenarios make any sense? It seems to me >>> that 1 and 2 are sci-fi >>> > given the current gateway solutions, while 3 might not be >>> possible because the >>> > gateway grabs the DTMF tones, or if it doesn't >>then it's an >>> ugly solution since >>> > signaling and media are all mixed together. >>> > >>> > Thanks, >>> > Serban >>> >>> -- >>> Jonathan D. Rosenberg 72 Eagle >>Rock Ave. >>> Chief Scientist First Floor >>> dynamicsoft East >>Hanover, NJ 07936 >>> jdrosen@dynamicsoft.com FAX: >>(973) 952-5050 >>> http://www.cs.columbia.edu/~jdrosen PHONE: >>(732) 741-7244 >>> http://www.dynamicsoft.com >>> >>> >>> _______________________________________________ >>> SIP mailing list >>> SIP@lists.bell-labs.com >>> http://lists.bell-labs.com/mailman/listinfo/sip >>> >> >> >>_______________________________________________ >>SIP mailing list >>SIP@lists.bell-labs.com >>http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 16: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 ESMTP id QAA12380 for ; Fri, 7 Jul 2000 16:28:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A5A08443CF; Fri, 7 Jul 2000 16:27:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id F376F443B0 for ; Fri, 7 Jul 2000 16:27:17 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA20803; Fri, 7 Jul 2000 16:28:43 -0400 (EDT) Message-ID: <39663D1D.B73DB10A@dynamicsoft.com> Date: Fri, 07 Jul 2000 16:27:09 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Brett Tate Cc: Henning Schulzrinne , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Brett Tate wrote: > > What's wrong with allowing a re-INVITE with a > new "o=" (or maybe the same "o=") to indicate > that all previous SDP > information is obsolete? Several things: 1. This is not backwards compatible. 2. o= is a session level field so it doesn't let you remove individual media streams. If we are to consider the new session id indicator in the o= field as the sign that all media streams are being replaced, we would have no way of modifying or removing some of the streams. > I think that this would > greatly increase the flexibility of 3rd party call > controllers. You are missing my point: it will not. Everything you want to achieve is already possible within current spec. To change it in a not backwards compatible way one needs better arguments than "we could do the same thing some other way". > It would also make it easier to attach > a SIP stack to end points which already generate > complete non-SIP specific SDPs. Why? The SDP in SIP messages is 100% compliant with RFC2327. > It also > reduces the overhead of having to continually > store and pass around "m=" lines with 0 ports in > re-INVITEs. What overhead? Bandwidth? We've been through this when we discussed text-based vs. ASN.1. If you can't afford signaling overhead you probably shouldn't even bother trying to set up the media session in the first place. > I can see potential uses for adding the "m=" lines > with 0 ports within 200 responses or "Delayed Media" > ACKs; however I'm not sure the benefits outweigh the > restriction of forcing the use of a "SIP specific" SDP. > > What are the benefits of using the "m=" with port 0 in > a re-INVITE? It's already in the spec and gives you all the flexibility you need. It's a somewhat clumsy solution but it works and is implemented by quite a few people by now. Regards, Igor Slepchin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 7 17:23:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13557 for ; Fri, 7 Jul 2000 17:23:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 53B1C443D3; Fri, 7 Jul 2000 17:22:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E26B44336 for ; Fri, 7 Jul 2000 17:22:44 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FXC00E01JDRU3@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 7 Jul 2000 21:22:39 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FXC00E1OJDRHC@firewall.mcit.com>; Fri, 07 Jul 2000 21:22:39 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) id <0FXC00601J9KBI@dgismtp01.wcomnet.com>; Fri, 07 Jul 2000 21:22:39 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FXC00601J8QAQ@dgismtp01.wcomnet.com>; Fri, 07 Jul 2000 21:19:43 +0000 (GMT) Received: from C25776A ([166.35.248.138]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0FXC003FJJ8GSM@dgismtp01.wcomnet.com>; Fri, 07 Jul 2000 21:19:29 +0000 (GMT) Date: Fri, 07 Jul 2000 16:19:19 -0500 From: Henry Sinnreich Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) In-reply-to: <006e01bfe7cd$30e3a340$276fa8c0@empowertel.com> To: rajeev@empowertel.com Cc: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The issue of "softswitches" - the good, the bad and the ugly in the context of the Internet architecture should IMHO be the topic of an IETF plenary, similar to the WAP discussion at the 47th IETF. On another venue, there will be a "SIP and Softswitch" session at the VON Fall 2000 with four speakers from the industry. See Session 1 at http://pulver.com/von/schedule.html Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rajeev Gupta >Sent: Thursday, July 06, 2000 11:38 PM >To: 'Henry Sinnreich' >Cc: sip@lists.bell-labs.com >Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) > > >> Henry Sinnreich wrote: >> Would you really have your analog phones controlled by the >> Telco, rather then being able to point them to any SIP server >> of your choice? > >1) As far as I know, your analog phones *are* >controlled by the telco. It is >a dumb device, acting upon the stimulus of the network >(controller). To a >degree, a GCP phone (or an IAD that connects to an >analog phone) would >simulate similar functionality. > >2) You have the choice today to run your SIP UA on >your desktop connected to >your ISP, and thus talk to any SIP server of your >choice. Similarly, you >could connect your GCP phone or IAD to any MGC that >will talk to you. The >protocol model (SIP vs GCP) does not imply a business >model (open/free vs >controlled/fee). > >3) This is not a technical issue, rather a business >issue of whether MGCs >provide their service for free, like today's SIP >servers. It is not hard to >imagine that SIP servers will evolve to provide >value-add services for a >fee, just as some folks may deploy experimental MGCs >that, like SIP proxies, >provide free services (clearly net-to-net calls, that >do not gateway to the >PSTN, can be provided free of cost, and there are many >examples of that >today). > >4) Given that you can use the "free" Internet for >voice using the protocol >of your choice (SIP, GCP, H.323, etc.), why then would >you want a fee-based >service? Clearly, this will be driven by additional >values the service >provider can deliver such as SLAs, QoS, enhanced services, etc. > >It seems you are mixing the SIP vs GCP argument with >the business model of >delivering services to users. > > >Rajeev Gupta >empowerTel Networks >475 Sycamore Drive, Milpitas, CA 95035 >Phone: +1 408 519 7136 >Fax: +1 408 519 7399 >mailto:rajeev@empowertel.com >http://www.empowertel.com > >Personally, I would always prefer a SIP >Ethernet to black phone adapter that gives me free choice of >service provider to xGCP phones controlled by the Telco as in >old times. Would you really have your analog phones controlled >by the Telco, rather then being able to point them to any SIP >server of your choice? > >Henry > >>-----Original Message----- >>From: Matt Holdrege [mailto:matt@ipverse.com] >>Sent: Monday, July 03, 2000 4:06 PM >>To: Henry Sinnreich >>Cc: 'Neil Deason'; Gardell, Steve; sip@lists.bell-labs.com >>Subject: RE: Softswitches (was Re: [SIP] SIP->XML->SOAP) >> >> >>At 02:47 PM 7/3/00 -0500, Henry Sinnreich wrote: >>>Problems seem to arise when circuit switch vendors >promote the >>>softswitch as an "exterior" service platform, across the net. >>>Even without going into the technical issues, it >>seems we would >>>then end up with a "Softswitchnet" instead of the >>Internet. This >>>seemed far fetched to me until I actually heard a >>circuit switch >>>vendor promoting the "Next Generation Public Network" that >>>actually went so far as to discard the Internet completely! >> >>There is nothing we can do about vendor marketing >>approaches here. >> >>>More problems arise when a GC is promoted to control >>IP phones. >>>In this case, a competitor to the operator for that >>GC could not >>>extend features to the GC controlled phones. This is a prime >>>example of fogging up the Internet, actually of reinventing >>>unequal access at the control level. Besides, how do you >>>integrate the services of xGCP phones with other >>services on the >>>Internet? >> >>There is nothing we can do about competitive control >>of phones or services >>here. All we can do is build protocols. How they are >>used in the above >>context is way outside our scope. >> >>>The above may be mistaken opinions, but there are >>also questions >>>such as, how does a softswitch environment handle: >>>Presence? >>>Instant Messaging? >>>Unified Messaging? >>>Caller and called preferences? >>>Mobility? >> >>The Softswitch could incorporate each of those >>features. But the more >>likely scenario is that they would use SIP to >>communicate to ASP's that >>provide those features. A SIP phone may not need a >>softswitch to do this, >>but the umpteen billion non-SIP phones need a little help. >> >>This style of open service delivery is one of the >>great things about our >>next-gen architecture. >> >>>Some time ago, SIP and H.323 comparisons were made >in a number >>>of places. Is it now time to make SIP-softswitch comparisons? >> >>SIP and Softswitches are not mutually exclusive. >>Pretty much all >>Softswitches speak SIP now or will in the near future. >> > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/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 Jul 7 18:31:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14784 for ; Fri, 7 Jul 2000 18:31:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C16B4443FE; Fri, 7 Jul 2000 18:20:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lists.bell-labs.com (Postfix) with SMTP id 920FE443ED for ; Fri, 7 Jul 2000 18:20:25 -0400 (EDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Jul 2000 15:11:02 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id <3ND1KNCV>; Fri, 7 Jul 2000 15:11:01 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01FF581B@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Henry Sinnreich'" , "Culpepper, Bert" , "Gardell, Steve" , "'Jonathan Rosenberg'" , Serban Tatu Cc: siplist Subject: RE: [SIP] authentication at gateway Date: Fri, 7 Jul 2000 15:10:59 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Client specific knowledge, such as MGCP inside is IMHO a very > bad architecture. Yep. MGCP is designed to stop at the "call agent" (or MGC, or softswitch.) The combination of the call agent + a set of MGCP controlled gateways should behave as one large SIP platform. It should definitely not expose its internals to 3rd parties. The whole problem of DTMF detection is nasty, but the rules are basically the following: there are uses of DTMF that are essentially internal to the call-agent+gateway combination, which can use the MGCP event/signal mechanism. Some of these uses may be in response to signalling events, that trigger some service inside the call agent. Using DTMF here is a local choice; a gui based client would probably use pop up windows and menus instead; MGCP events are the equivalent to these pop up menus. Then, there are uses of DTMF in which DTMF is essentially a substitute to voice recognition. The SIP controlled gateway is connected to a remote server, that pops a set of questions. The simplest architecture there is to carry DTMF over RTP. If the server is only interested in DTMF signals, it can use SIP/SDP to negotiate a "tone" payload; if the server want to provide either DTMF or voice recognition, it should use a sufficently capable voice channel. (A problem here is that negotiating two audio channels within a single SDP command is almost impossible.) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 00:55:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20406 for ; Sat, 8 Jul 2000 00:55:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D5BBA443A9; Sat, 8 Jul 2000 00:55:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id ADE6944386 for ; Sat, 8 Jul 2000 00:55:08 -0400 (EDT) Received: from dynamicsoft.com (1Cust186.tnt1.freehold.nj.da.uu.net [63.17.113.186]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22114; Sat, 8 Jul 2000 00:56:35 -0400 (EDT) Message-ID: <3966B4CF.171E14E5@dynamicsoft.com> Date: Sat, 08 Jul 2000 00:57:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Brett Tate , Henning Schulzrinne , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> <39663D1D.B73DB10A@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > Several things: > 1. This is not backwards compatible. This is pretty much a showstopper. > 2. o= is a session level field so it doesn't let you remove individual > media streams. If we are to consider the new session id indicator in the > o= field as the sign that all media streams are being replaced, we would > have no way of modifying or removing some of the streams. > > > I think that this would > > greatly increase the flexibility of 3rd party call > > controllers. > > You are missing my point: it will not. Everything you want to achieve is > already possible within current spec. To change it in a not backwards > compatible way one needs better arguments than "we could do the same > thing some other way". Let me emphasize Igors point. What you will want to do most of the time in 3pcc is change the *address* that a particular media stream is sent to. This does not require adding a new media stream. It simply requires resending the SDP with that particular stream having a new address. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 00:59:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20428 for ; Sat, 8 Jul 2000 00:59:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 55B2D443D2; Sat, 8 Jul 2000 00:58:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 998194439C for ; Sat, 8 Jul 2000 00:58:00 -0400 (EDT) Received: from dynamicsoft.com (1Cust186.tnt1.freehold.nj.da.uu.net [63.17.113.186]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22122; Sat, 8 Jul 2000 00:59:17 -0400 (EDT) Message-ID: <3966B571.8881F2E@dynamicsoft.com> Date: Sat, 08 Jul 2000 01:00:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Henning Schulzrinne , vkg@lucent.com, "Vakil, Mohammad" , Dvir Oren , SIP Subject: Re: [SIP] OK with no ACK References: <91522176F94CD4119FAB00B0D0492B4312AC87@ORT-EXCH> <3964A355.4535A9C7@dynamicsoft.com> <3964E42F.28820A03@lucent.com> <3964E942.6F03ED41@cs.columbia.edu> <396558E4.98C35081@dynamicsoft.com> <3965F7CD.3FFD9914@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > > > > If the caller wants to hang up a call, but hasn't yet received a final > > response, it can send a CANCEL or a BYE. > > It can also send both CANCEL and BYE to get the best of both worlds. > Note that this takes nearly no extra time since you can send BYE right > after CANCEL. I don't really see the problem with having this behavior > dependent on the state: the state has to be maintained anyway, right? > And I don't think that an extra "if" statement complicates things all > that much. I don't think sending both at the same time really helps. The BYE still won't have tags or be routed with route headers, and thus may still miss some endpoints. Should the CANCEL pass a 200 OK on the wire (from an endpoint which didn't get the BYE), well, you still have inconsistent state. Sending CANCEL, and then BYE once 200 OKs come, is the only sure-fire way to not have inconsistent 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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 01:14:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21515 for ; Sat, 8 Jul 2000 01:14:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E819443E3; Sat, 8 Jul 2000 01:14:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 64E7E443B5 for ; Sat, 8 Jul 2000 01:14:30 -0400 (EDT) Received: from dynamicsoft.com (1Cust186.tnt1.freehold.nj.da.uu.net [63.17.113.186]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA22135; Sat, 8 Jul 2000 01:11:53 -0400 (EDT) Message-ID: <3966B865.8F23000A@dynamicsoft.com> Date: Sat, 08 Jul 2000 01:13:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: A Srinath , sip@lists.bell-labs.com Subject: Re: [SIP] Routing of ACK References: <003701bfe80d$e7a25e60$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > Hi, > > consider the following scenario. > > > > ->B > > | > > A -> P - > > | > > ->C > > > > A sends an INVITE to proxy P with (CID=x, CSEQ=1, TO=y, FROM=z) > > > > P forks the request to B and C. with appropriate branch tags in VIA. > > > > Both B and C respond with 200 OK. which reach A. > > > > A finds out about 2 call legs using the tags in the TO field. > > > > A sends out 2 ACK's for both the legs with the tags in the TO. > > It sends both of them to the proxy P. > > > > The question is how does P find out where to route the ACK. > > > > a. Does it route both the ACK's to both locations. > > b. Does it maintain the call state to know which tag goes where. I'll note that in rfc2543bis, this should pretty much never happen. In the bis draft, the final 200 OK response MUST contain a Contact header. This means that either (1) the proxy record-routes, in which case the ACKs will each contain (different) route headers which tell the proxy where to send the request, or (2) the proxy doesn't record-route, in which case it gets sent directly to the UAS, since there was a contact. That aside, should it arrive anyway, the ACK should be routed just as any other new request. Apply routing logic, which presumably causes it to be forked to both locations. The tags will help identify for which UAS the ACK is meant. > There's no good reason (that I can think of), however, that the > proxy can't be even more optimal by noting the tags seen on branches, > and only routing ACKs to the appropriate branches. If you are stateful, you can also do 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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 01:34:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24240 for ; Sat, 8 Jul 2000 01:34:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C396C443C4; Sat, 8 Jul 2000 01:34:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A2B82443B9 for ; Sat, 8 Jul 2000 01:34:02 -0400 (EDT) Received: from dynamicsoft.com (1Cust186.tnt1.freehold.nj.da.uu.net [63.17.113.186]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA22157; Sat, 8 Jul 2000 01:35:16 -0400 (EDT) Message-ID: <3966BDE0.9EE131C7@dynamicsoft.com> Date: Sat, 08 Jul 2000 01:36:32 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon.Peterson@Level3.com Cc: Gonzalo.Camarillo@lmf.ericsson.se, sip@lists.bell-labs.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP References: <87A245E94948D3118DE30008C716B01301523A03@c0005v1idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jon.Peterson@Level3.com wrote: > > I have a question about the flow below. When C has acquired the provisional > media (183) SDP from A, is that the time at which C would like to send an > INVITE to B? Or would C rather wait until someone actually picks up the > phone at A? Obviously, in a telephone-based service, if A has not yet > answered when B starts ringing, this could lead to confusion, if the service > is structured in such a way that the order of operations is important. Good observation. Interestingly, 3pcc as you have defined (INVITE the 2nd user once the first answers) and preconditions fundamentally contradict each other. Preconditions says that you don't send a 200 OK until resources are reserved; but, you can't reserve resources until you have the address of the other party with whom you are exchanging media. Getting this address requires C to send an INVITE to the other party, so it can get back a 183 with this information. This contradicts the type of 3pcc you desire, where you don't want to send an INVITE to the the 2nd party until the first answers with a 200 OK. Note that its not sending the INVITE which you really want to avoid, but you want to make sure one phone rings only after the other has picked up. This, actually, can be accomplished if we make COMET symmetrical, in the sense that the caller and called party must both send each other COMET in order to cause ringing at the other side. WIth this, A and B will both eventually send COMET to C (note that neither A or B are ringing). Now, C can send a COMET to A, and then wait for A to answer the phone (200 OK), before sending a COMET to B. This causes As phone to ring first, and then Bs phone to ring only after A picks up, as desired. The reverse can also be accomplished. This allows control of the ordering of ringing even with preconditions. This, however, is not how preconditions work now. Do people believe it valuable to define such symmetry in order to enable this kind of 3pcc service? 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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 08:38:48 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05387 for ; Sat, 8 Jul 2000 08:38:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1BA414435B; Sat, 8 Jul 2000 08:38:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prserv.net (out2.prserv.net [32.97.166.32]) by lists.bell-labs.com (Postfix) with ESMTP id 07D2344336 for ; Sat, 8 Jul 2000 08:38:42 -0400 (EDT) Received: from cs.columbia.edu ([129.37.75.17]) by prserv.net (out2) with SMTP id <2000070812375222902q1oaqe>; Sat, 8 Jul 2000 12:37:53 +0000 Message-ID: <396722BB.26C1BF39@cs.columbia.edu> Date: Sat, 08 Jul 2000 08:46:51 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Brett Tate , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> <39663D1D.B73DB10A@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I think a more interesting question is what to do if you do receive a new SDP where a media line is "missing" (i.e., the SDP in the 200 has fewer m= lines than the INVITE) or "misaligned" (e.g., the INVITE has m=audio,m=video while the 200 has m=video,m=audio). Given that many simple implementations probably generate fixed SDP (audio only), this situation is going to be common. I don't think implementations need to do much: as long as I start applications based on the SDP that I receive and use my own advertised ports to receive things will work fine for common single-instance-of-media cases. I suppose we should test whether anybody at the bake-off actually handles port 0 or multiple audio (say) lines correctly. My recollection is that it was difficult to impossible to find somebody that could test a second media (video) with us, let alone two instances of a media type. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 12:21:06 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07025 for ; Sat, 8 Jul 2000 12:21:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AAA344366; Sat, 8 Jul 2000 12:20:26 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id BCF2D44336 for ; Sat, 8 Jul 2000 12:20:22 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id LAA12580; Sat, 08 Jul 2000 11:22:49 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Sat, 8 Jul 2000 11:17:37 -0500 Message-ID: From: "Culpepper, Bert" To: Henry Sinnreich , "Culpepper, Bert" , "Gardell, Steve" , "'Jonathan Rosenberg'" , Serban Tatu Cc: siplist Subject: RE: [SIP] authentication at gateway Date: Sat, 8 Jul 2000 11:17:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I understand and agree that support for a signaling protocol inside another signaling protocol is highly undesirable. However, SIP does not support mid-call terminal events that I'm aware of. If we can transporting ISUP and QSIG inside of SIP why can't a subset of MGCP and Megaco be transported inside of SIP (for those who wish to support it)? Anyway, I respect that the type of functionality I've discussed within SIP probably violates the principles of a protocol and I appreciate the feedback. Mid-call terminal events are outside of the scope of SIP. Thanks, Bert (I apologize for changing the subject of this thread.) -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com] Sent: Friday, July 07, 2000 4:19 PM To: Culpepper, Bert; Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu Cc: siplist Subject: RE: [SIP] authentication at gateway A SIP "only" (non >MGCP/Megago specific) solution >for PSTN-phone event detection and reporting (as has >also been proposed) >would allow the service to be agnostic to the endpoint >type but may not map >to MGCP and Megaco. There are several reasons why the service has to be agnostic of the type of client. Such as for 1. the ease of introduction of new services and 2. any to any communications. Client specific knowledge, such as MGCP inside is IMHO a very bad architecture. Henry >-----Original Message----- >From: Culpepper, Bert >[mailto:bert.culpepper@intervoice-brite.com] >Sent: Wednesday, July 05, 2000 9:46 PM >To: Henry Sinnreich; Gardell, Steve; 'Jonathan >Rosenberg'; Serban Tatu >Cc: siplist >Subject: RE: [SIP] authentication at gateway > > >My study of gateway capabilities has not revealed an >answer to Serban's >question other than that authentication (via the >scenarios described) is not >available in gateways today and is not likely to show >up anytime soon if at >all. IMO, the most likely solution is very much like >#3 for the scenario >given. An MCGP or Megaco compliant gateway can >collect and report DTMF >digits in signaling separate from the media. However, >this requires the SIP >UAS to also "speak" one of these protocols (obviously, >not a good solution >at all). In networks where PSTN phones are served >there is also likely to >be a Gateway Controller that provides an interface >between the gateway and >SIP UA. A practical and feasible approach is to >extend the gateway's >MGCP/Megaco-based event detection and reporting to SIP >UAs (for which at >least one solution has been proposed). The >application-specific prompts can >be provided by the application server and leave the >gateway to performing >its "gateway" functions. A SIP "only" (non >MGCP/Megago specific) solution >for PSTN-phone event detection and reporting (as has >also been proposed) >would allow the service to be agnostic to the endpoint >type but may not map >to MGCP and Megaco. > >Maybe we'll see a solution in the near future for all >terminals (SIP, PSTN, >others?). > >Bert > >-----Original Message----- >From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com] >Sent: Wednesday, July 05, 2000 6:02 PM >To: Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu >Cc: siplist >Subject: RE: [SIP] authentication at gateway > > >>I suggest that the appropriate >>"converged" >>architecture is to have authentication controlled from outside >>the gateway and to implement it via a SIP Proxy(like?) >>element in >>situations where we want the core service to be >>agnostic as to whether >>the endpoint is a gateway or a UA. > >Exactly right! > >Henry > >>-----Original Message----- >>From: sip-admin@lists.bell-labs.com >>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >>Gardell, Steve >>Sent: Wednesday, July 05, 2000 6:42 AM >>To: 'Jonathan Rosenberg'; Serban Tatu >>Cc: siplist >>Subject: RE: [SIP] authentication at gateway >> >> >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>> Sent: Wednesday, July 05, 2000 12:01 AM >>> To: Serban Tatu >>> Cc: siplist >>> Subject: Re: [SIP] authentication at gateway >>> >>> >>> THe most likely scenario is one you left out: the >>prompting and >>> collection for the PIN are all performed by the originating >>> gateway. In >>> general, the entity demanding authentication will >>not know that the >>> request is through a gateway. I believe its unlikely >>the entity would >>> return 200 OK, or even a 401 with content. Rather, >>just a 401. >>> >>> So, upon receiving the 401, the gateway performs some local >>> operation to >>> get the username and password. Perhaps it plays out an >>> announcement and >>> collects the username/password; perhaps they are >>simply established >>> ahead of time and stored in a database - the gateway >>just fetches them >>> when prompted for authentication. >>> >> >> >>A practical issue with this approach is that gateways >are often >>deployed in support of many different services that may have >>different authentication requirements. Placing all of the >>authentication smarts in the gateway makes it >difficult to roll >>out new services. Now admittedly this is a "telco >centric" view >>of the service world - I suggest that the appropriate >>"converged" >>architecture is to have authentication controlled from outside >>the gateway and to implement it via a SIP Proxy(like?) >>element in >>situations where we want the core service to be >>agnostic as to whether >>the endpoint is a gateway or a UA. >> >> >>> -Jonathan R. >>> >>> Serban Tatu wrote: >>> > >>> > Hi, >>> > >>> > How is authentication performed by a SIP-enabled gateway? >>> Let's say somebody on >>> > a PSTN phone wants to gain access to a service and >>> therefore has to provide a >>> > username/password. Some scenarios come to mind >>(newbie >>> > here): >>> > >>> > Scenario 1 (smart gateway): >>> > >>> > - SIP UAS at service side sends a 401 unauthorized as a >>> response to the INVITE. >>> > The response contains a voice prompt audio file (e.g. >>> Gimme >>> > username/password). >>> > - gateway is so smart that it knows how to play the prompt >>> and collect DTMF >>> > tones representing username and password, which it then >>> sends back encoded >>> > somehow to the service. >>> > >>> > Scenario 2 (not so smart gateway): >>> > >>> > - SIP UAS at service side sends back a 200 OK response to >>> the INVITE. The >>> > response contains the voice prompt as before. >>> > - gateway knows how to play the audio file, sends ACK, >>> media connections are >>> > open. >>> > - SIP UAS at service side then sends an INFO >>message with a >>> DTMF collection >>> > scheme (voice prompt could also be sent here). >>> > - gateway collects the tones and sends them back with >>> another INFO message. >>> > >>> > Scenario 3 (dumb gateway): >>> > >>> > - SIP UAS at service side sends back a 200 OK response to >>> the INVITE. >>> > - gateway and SIP UAS establish their media channels. >>> > - service then plays the whole authentication scenario >>> through the media >>> > channels. Gateway lets DTMF tones flow through the >>media path. >>> > >>> > Do any of these scenarios make any sense? It seems to me >>> that 1 and 2 are sci-fi >>> > given the current gateway solutions, while 3 might not be >>> possible because the >>> > gateway grabs the DTMF tones, or if it doesn't >>then it's an >>> ugly solution since >>> > signaling and media are all mixed together. >>> > >>> > Thanks, >>> > Serban >>> >>> -- >>> Jonathan D. Rosenberg 72 Eagle >>Rock Ave. >>> Chief Scientist First Floor >>> dynamicsoft East >>Hanover, NJ 07936 >>> jdrosen@dynamicsoft.com FAX: >>(973) 952-5050 >>> http://www.cs.columbia.edu/~jdrosen PHONE: >>(732) 741-7244 >>> http://www.dynamicsoft.com >>> >>> >>> _______________________________________________ >>> SIP mailing list >>> SIP@lists.bell-labs.com >>> http://lists.bell-labs.com/mailman/listinfo/sip >>> >> >> >>_______________________________________________ >>SIP mailing list >>SIP@lists.bell-labs.com >>http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/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 Jul 8 12:22:51 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07036 for ; Sat, 8 Jul 2000 12:22:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A6B65443C8; Sat, 8 Jul 2000 12:20:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id BBE76443C2 for ; Sat, 8 Jul 2000 12:20:51 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id LAA12582; Sat, 08 Jul 2000 11:23:19 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Sat, 8 Jul 2000 11:18:07 -0500 Message-ID: From: "Culpepper, Bert" To: Jonathan Rosenberg Cc: Henry Sinnreich , "Gardell, Steve" , Serban Tatu , siplist Subject: RE: [SIP] authentication at gateway Date: Sat, 8 Jul 2000 11:18:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I expect it's obvious I don't have a lot of experience discussing a topic on this list :), sorry for merging issues (and going beyond the subject of this thread). I would like to comment though. Means of authentication are provided by SIP. And for the scenario described in the original message, 183 is a good solution and works during session establishment (for PSTN-based terminals specifically). Now providing a means within SIP to access MGCP/Megaco functionality within an UA that supports both SIP and MGCP/Megaco (a Softswitch for example) is not too far fetched is it? I look forward to seeing more discussion on endpoint control by SIP-based service applications. (I'll wait patiently :)). Bert -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 05, 2000 11:59 PM To: Culpepper, Bert Cc: Henry Sinnreich; Gardell, Steve; Serban Tatu; siplist Subject: Re: [SIP] authentication at gateway You are merging a bunch of issues here which are really separate. I agree that each service will have its own means of authenticating users of that service. SIP already provides three ways of obtaining authentication for requests - http basic, http digest, and pgp. If the service wishes to use these mechanisms to authenticate subscribers, than that is its decision. If the entity acting as UAC (gateway or softswitch) cannot obtain information required to provide credentials, then users through that gateway can't access those services. If an application wishes to authenticate through a media conversation, this is also its choice. Doing so works just fine now with SIP, by collecting DTMF or doing speech recognition or whatever, as part of the media stream, using 183, for example, to establish early media. This will alleviate the gateway from the "burden" of authentication from each service, as requested, and do so in a manner which works for gateways, PC clients, IP phones, or whatever, in a uniform fashion. These mechanisms are not all that secure in reality (remember, this ain't the PSTN anymore), but thats also a separate issue. It is a separate and orthogonal issue as to whether the DTMF is carried within SIP, and orthogonal and separate once again about whether SIP UAs need to speak megaco in order to be controlled by a device providing services. I have many comments on this issue, and it is on my todo list to collect them and respond to the earlier thread on the subject. In any case most of you can guess my feelings on mandating megaco in a SIP UA in order to access services. -Jonathan R. "Culpepper, Bert" wrote: > > My study of gateway capabilities has not revealed an answer to Serban's > question other than that authentication (via the scenarios described) is not > available in gateways today and is not likely to show up anytime soon if at > all. IMO, the most likely solution is very much like #3 for the scenario > given. An MCGP or Megaco compliant gateway can collect and report DTMF > digits in signaling separate from the media. However, this requires the SIP > UAS to also "speak" one of these protocols (obviously, not a good solution > at all). In networks where PSTN phones are served there is also likely to > be a Gateway Controller that provides an interface between the gateway and > SIP UA. A practical and feasible approach is to extend the gateway's > MGCP/Megaco-based event detection and reporting to SIP UAs (for which at > least one solution has been proposed). The application-specific prompts can > be provided by the application server and leave the gateway to performing > its "gateway" functions. A SIP "only" (non MGCP/Megago specific) solution > for PSTN-phone event detection and reporting (as has also been proposed) > would allow the service to be agnostic to the endpoint type but may not map > to MGCP and Megaco. > > Maybe we'll see a solution in the near future for all terminals (SIP, PSTN, > others?). > > Bert > > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com] > Sent: Wednesday, July 05, 2000 6:02 PM > To: Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu > Cc: siplist > Subject: RE: [SIP] authentication at gateway > > >I suggest that the appropriate > >"converged" > >architecture is to have authentication controlled from outside > >the gateway and to implement it via a SIP Proxy(like?) > >element in > >situations where we want the core service to be > >agnostic as to whether > >the endpoint is a gateway or a UA. > > Exactly right! > > Henry > > >-----Original Message----- > >From: sip-admin@lists.bell-labs.com > >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of > >Gardell, Steve > >Sent: Wednesday, July 05, 2000 6:42 AM > >To: 'Jonathan Rosenberg'; Serban Tatu > >Cc: siplist > >Subject: RE: [SIP] authentication at gateway > > > > > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >> Sent: Wednesday, July 05, 2000 12:01 AM > >> To: Serban Tatu > >> Cc: siplist > >> Subject: Re: [SIP] authentication at gateway > >> > >> > >> THe most likely scenario is one you left out: the > >prompting and > >> collection for the PIN are all performed by the originating > >> gateway. In > >> general, the entity demanding authentication will > >not know that the > >> request is through a gateway. I believe its unlikely > >the entity would > >> return 200 OK, or even a 401 with content. Rather, > >just a 401. > >> > >> So, upon receiving the 401, the gateway performs some local > >> operation to > >> get the username and password. Perhaps it plays out an > >> announcement and > >> collects the username/password; perhaps they are > >simply established > >> ahead of time and stored in a database - the gateway > >just fetches them > >> when prompted for authentication. > >> > > > > > >A practical issue with this approach is that gateways are often > >deployed in support of many different services that may have > >different authentication requirements. Placing all of the > >authentication smarts in the gateway makes it difficult to roll > >out new services. Now admittedly this is a "telco centric" view > >of the service world - I suggest that the appropriate > >"converged" > >architecture is to have authentication controlled from outside > >the gateway and to implement it via a SIP Proxy(like?) > >element in > >situations where we want the core service to be > >agnostic as to whether > >the endpoint is a gateway or a UA. > > > > > >> -Jonathan R. > >> > >> Serban Tatu wrote: > >> > > >> > Hi, > >> > > >> > How is authentication performed by a SIP-enabled gateway? > >> Let's say somebody on > >> > a PSTN phone wants to gain access to a service and > >> therefore has to provide a > >> > username/password. Some scenarios come to mind > >(newbie > >> > here): > >> > > >> > Scenario 1 (smart gateway): > >> > > >> > - SIP UAS at service side sends a 401 unauthorized as a > >> response to the INVITE. > >> > The response contains a voice prompt audio file (e.g. > >> Gimme > >> > username/password). > >> > - gateway is so smart that it knows how to play the prompt > >> and collect DTMF > >> > tones representing username and password, which it then > >> sends back encoded > >> > somehow to the service. > >> > > >> > Scenario 2 (not so smart gateway): > >> > > >> > - SIP UAS at service side sends back a 200 OK response to > >> the INVITE. The > >> > response contains the voice prompt as before. > >> > - gateway knows how to play the audio file, sends ACK, > >> media connections are > >> > open. > >> > - SIP UAS at service side then sends an INFO > >message with a > >> DTMF collection > >> > scheme (voice prompt could also be sent here). > >> > - gateway collects the tones and sends them back with > >> another INFO message. > >> > > >> > Scenario 3 (dumb gateway): > >> > > >> > - SIP UAS at service side sends back a 200 OK response to > >> the INVITE. > >> > - gateway and SIP UAS establish their media channels. > >> > - service then plays the whole authentication scenario > >> through the media > >> > channels. Gateway lets DTMF tones flow through the > >media path. > >> > > >> > Do any of these scenarios make any sense? It seems to me > >> that 1 and 2 are sci-fi > >> > given the current gateway solutions, while 3 might not be > >> possible because the > >> > gateway grabs the DTMF tones, or if it doesn't > >then it's an > >> ugly solution since > >> > signaling and media are all mixed together. > >> > > >> > Thanks, > >> > Serban > >> > >> -- > >> Jonathan D. Rosenberg 72 Eagle > >Rock Ave. > >> Chief Scientist First Floor > >> dynamicsoft East > >Hanover, NJ 07936 > >> jdrosen@dynamicsoft.com FAX: > >(973) 952-5050 > >> http://www.cs.columbia.edu/~jdrosen PHONE: > >(732) 741-7244 > >> http://www.dynamicsoft.com > >> > >> > >> _______________________________________________ > >> SIP mailing list > >> SIP@lists.bell-labs.com > >> http://lists.bell-labs.com/mailman/listinfo/sip > >> > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 13:06:12 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07402 for ; Sat, 8 Jul 2000 13:06:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A79504435F; Sat, 8 Jul 2000 13:06:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 630A84433B for ; Sat, 8 Jul 2000 13:05:59 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA07346; Sat, 8 Jul 2000 10:06:08 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA10820; Sat, 8 Jul 2000 10:05:58 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14695.24438.369773.155017@thomasm-u1.cisco.com> Date: Sat, 8 Jul 2000 10:05:58 -0700 (PDT) To: "Culpepper, Bert" Cc: Henry Sinnreich , "Gardell, Steve" , "'Jonathan Rosenberg'" , Serban Tatu , siplist Subject: RE: [SIP] authentication at gateway 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Culpepper, Bert writes: > If we can transporting ISUP and > QSIG inside of SIP why can't a subset of MGCP and Megaco be transported > inside of SIP (for those who wish to support it)? SIP is great and all, but IP seems like a much more efficient transport for MGCP/MEGACO. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 18:12:21 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09829 for ; Sat, 8 Jul 2000 18:12:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 07E704433D; Sat, 8 Jul 2000 18:12:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id CF1FF44336 for ; Sat, 8 Jul 2000 18:12:03 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FXE00J01GC2O4@firewall.mcit.com> for sip@lists.bell-labs.com; Sat, 8 Jul 2000 22:12:02 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FXE00G1DGC2FC@firewall.mcit.com>; Sat, 08 Jul 2000 22:12:02 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FXE00I01G9E30@pmismtp03.wcomnet.com>; Sat, 08 Jul 2000 22:10:26 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FXE00I01G9E2Z@pmismtp03.wcomnet.com>; Sat, 08 Jul 2000 22:10:26 +0000 (GMT) Received: from C25776A ([166.46.16.148]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FXE007CPG8WY1@pmismtp03.wcomnet.com>; Sat, 08 Jul 2000 22:10:11 +0000 (GMT) Date: Sat, 08 Jul 2000 17:11:37 -0500 From: Henry Sinnreich Subject: RE: [SIP] authentication at gateway In-reply-to: <14695.24438.369773.155017@thomasm-u1.cisco.com> To: Michael Thomas , "Culpepper, Bert" Cc: "Gardell, Steve" , "'Jonathan Rosenberg'" , Serban Tatu , siplist Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > SIP is great and all, but IP seems like a much > more efficient transport for MGCP/MEGACO. I understand MGCP/MEGACO needs SCTP for reliable transport across the net. Not that I think it is good idea, since you end up with a MGCP/MEGACO network under GC control instead of the open Internet. Henry >-----Original Message----- >From: Michael Thomas [mailto:mat@cisco.com] >Sent: Saturday, July 08, 2000 12:06 PM >To: Culpepper, Bert >Cc: Henry Sinnreich; Gardell, Steve; 'Jonathan >Rosenberg'; Serban Tatu; >siplist >Subject: RE: [SIP] authentication at gateway > > >Culpepper, Bert writes: > > If we can transporting ISUP and > > QSIG inside of SIP why can't a subset of MGCP and >Megaco be transported > > inside of SIP (for those who wish to support it)? > > SIP is great and all, but IP seems like a much > more efficient transport for MGCP/MEGACO. > > Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 21:36:15 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11575 for ; Sat, 8 Jul 2000 21:36:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 72B1E44364; Sat, 8 Jul 2000 21:35:54 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id D1B0644336 for ; Sat, 8 Jul 2000 21:35:50 -0400 (EDT) Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id VAA71728; Sat, 8 Jul 2000 21:35:45 -0400 (EDT) Message-ID: <06ca01bfe946$7f47fcf0$3102a8c0@broadsoft.com> From: "Brett Tate" To: "Henning Schulzrinne" Cc: "SIPbell-labs" References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> <39663D1D.B73DB10A@dynamicsoft.com> <396722BB.26C1BF39@cs.columbia.edu> Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis Date: Sat, 8 Jul 2000 21:39:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Henning Schulzrinne To: Igor Slepchin Cc: Brett Tate ; SIPbell-labs Sent: Saturday, July 08, 2000 8:46 AM Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis > I think a more interesting question is what to do if you do receive a > new SDP where a media line is "missing" (i.e., the SDP in the 200 has > fewer m= lines than the INVITE) or "misaligned" (e.g., the INVITE has > m=audio,m=video while the 200 has m=video,m=audio). Given that many > simple implementations probably generate fixed SDP (audio only), this > situation is going to be common. I completely agree. The n-th position of a given SDP having to match up with the n-th position of a corresponding SDP forces a SIP stack to have to tweak an SDP received from an upper layer or other protocol to make it SIP compliant. I assume that someone will correct me if the position alignment isn't SIP specific. :) > I don't think implementations need to > do much: as long as I start applications based on the SDP that I receive > and use my own advertised ports to receive things will work fine for > common single-instance-of-media cases. > > I suppose we should test whether anybody at the bake-off actually > handles port 0 or multiple audio (say) lines correctly. My recollection > is that it was difficult to impossible to find somebody that could test > a second media (video) with us, let alone two instances of a media type. If possible, this is why I would like to see any short comings with SIP's use of the SDP be addressed now instead of later. Thanks for reading my comments/concerns. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 8 22:41:42 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12799 for ; Sat, 8 Jul 2000 22:41:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D03F344376; Sat, 8 Jul 2000 22:41:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 033DC44364 for ; Sat, 8 Jul 2000 22:41:24 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA21446; Sat, 8 Jul 2000 22:41:21 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA29127; Sat, 8 Jul 2000 22:41:22 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Sat, 8 Jul 2000 22:41:11 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF6784FF@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Henry Sinnreich'" , Michael Thomas , "Culpepper, Bert" Cc: "Gardell, Steve" , "'Jonathan Rosenberg'" , Serban Tatu , siplist Subject: RE: [SIP] authentication at gateway Date: Sat, 8 Jul 2000 22:41:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Actually, Megaco is specified over a wide variety of transports including UDP, TCP and SCTP. In each case, there are mechanisms to assure "reliability", although the definition changes somewhat depending on many factors. SCTP is indeed a good choice in several scenarios, which I would suspect, would be the same kinds of situations where running SIP on SCTP would be appropriate. In many cases, as with sip, and MGCP, it is very appropriate to run Megaco over UDP, and I usually suggest you start that way. Brian > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com] > Sent: Saturday, July 08, 2000 6:12 PM > To: Michael Thomas; Culpepper, Bert > Cc: Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu; siplist > Subject: RE: [SIP] authentication at gateway > > > > SIP is great and all, but IP seems like a much > > more efficient transport for MGCP/MEGACO. > I understand MGCP/MEGACO needs SCTP for reliable transport > across the net. Not that I think it is good idea, since you end > up with a MGCP/MEGACO network under GC control instead of the > open Internet. > > Henry > > >-----Original Message----- > >From: Michael Thomas [mailto:mat@cisco.com] > >Sent: Saturday, July 08, 2000 12:06 PM > >To: Culpepper, Bert > >Cc: Henry Sinnreich; Gardell, Steve; 'Jonathan > >Rosenberg'; Serban Tatu; > >siplist > >Subject: RE: [SIP] authentication at gateway > > > > > >Culpepper, Bert writes: > > > If we can transporting ISUP and > > > QSIG inside of SIP why can't a subset of MGCP and > >Megaco be transported > > > inside of SIP (for those who wish to support it)? > > > > SIP is great and all, but IP seems like a much > > more efficient transport for MGCP/MEGACO. > > > > Mike > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 8 23:46:38 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13471 for ; Sat, 8 Jul 2000 23:46:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9863B443D2; Sat, 8 Jul 2000 23:46:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E561A44395 for ; Sat, 8 Jul 2000 23:46:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust27.tnt3.freehold.nj.da.uu.net [63.25.172.27]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA22747; Sat, 8 Jul 2000 23:47:27 -0400 (EDT) Message-ID: <3967F621.973F3304@dynamicsoft.com> Date: Sat, 08 Jul 2000 23:48:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Henning Schulzrinne , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> <39663D1D.B73DB10A@dynamicsoft.com> <396722BB.26C1BF39@cs.columbia.edu> <06ca01bfe946$7f47fcf0$3102a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Brett Tate wrote: > > ----- Original Message ----- > From: Henning Schulzrinne > To: Igor Slepchin > Cc: Brett Tate ; SIPbell-labs > Sent: Saturday, July 08, 2000 8:46 AM > Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis > > > I think a more interesting question is what to do if you do receive a > > new SDP where a media line is "missing" (i.e., the SDP in the 200 has > > fewer m= lines than the INVITE) or "misaligned" (e.g., the INVITE has > > m=audio,m=video while the 200 has m=video,m=audio). Given that many > > simple implementations probably generate fixed SDP (audio only), this > > situation is going to be common. > > I completely agree. The n-th position of a given SDP having > to match up with the n-th position of a corresponding SDP > forces a SIP stack to have to tweak an SDP received from > an upper layer or other protocol to make it SIP compliant. > > I assume that someone will correct me if the position > alignment isn't SIP specific. :) I think its fair to say that it isn't. Its a general problem associated with correlating multiple SDPs associated with the same session. This can happen even in SAP. Lets say a SAP announcement is sent, containing SDP 1 with two audio and a video stream. Later on, an updated SDP (SDP 2) is sent out. This SDP has one audio and one video stream. Now, if my media tools started off based on SDP 1, and now SDP 2 comes, which audio stream should be removed? This is the same problem we have in SIPs usage of SDP. Aligning media streams between SDP allows us to determine this correlation. > > > I don't think implementations need to > > do much: as long as I start applications based on the SDP that I receive > > and use my own advertised ports to receive things will work fine for > > common single-instance-of-media cases. > > > > I suppose we should test whether anybody at the bake-off actually > > handles port 0 or multiple audio (say) lines correctly. My recollection > > is that it was difficult to impossible to find somebody that could test > > a second media (video) with us, let alone two instances of a media type. > > If possible, this is why I would like to see any short comings > with SIP's use of the SDP be addressed now instead of later. The alignment of media streams via positioning works just fine. Is it elegant - no. But, it works, and its already there. If there is an actual bug or unaddressed issue, then we can resolve it. But, I don't want to change SDP usage in SIP just because its not elegant. We really have to worry about backwards compatibility. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 8 23:56:29 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13584 for ; Sat, 8 Jul 2000 23:56:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A2221443EB; Sat, 8 Jul 2000 23:55:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7BF91443A6 for ; Sat, 8 Jul 2000 23:55:41 -0400 (EDT) Received: from dynamicsoft.com (1Cust27.tnt3.freehold.nj.da.uu.net [63.25.172.27]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA22756; Sat, 8 Jul 2000 23:56:52 -0400 (EDT) Message-ID: <3967F856.EBED41A6@dynamicsoft.com> Date: Sat, 08 Jul 2000 23:58:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: Henry Sinnreich , "Gardell, Steve" , Serban Tatu , siplist Subject: Re: [SIP] authentication at gateway References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Culpepper, Bert" wrote: > > I understand and agree that support for a signaling protocol inside another > signaling protocol is highly undesirable. However, SIP does not support > mid-call terminal events that I'm aware of. If we can transporting ISUP and > QSIG inside of SIP why can't a subset of MGCP and Megaco be transported > inside of SIP (for those who wish to support it)? Because ISUP provides information that is very much related to the function of SIP in the first place - initiation of sessions between end points. There is a natural mapping of ISUP messages to SIP messages for this very reason - both are call establishment protocols. If you ignore the ISUP, the SIP is still useful and makes sense by itself. The semantics of the protocol are driven off SIP, *not* the ISUP in the payload. That is not the case if you tunnel megaco over SIP. I would not advocate tunneling DHCP over SIP, HTTP over SIP, or SLP over SIP, since those protocols don't do the same thing SIP does. Same with megaco/mgcp. Tunneling them over SIP serves no purpose. SIP is not a good transfer protocol (see the Guidelines for Authors of SIP Extensions: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-guidelines-00.txt). Just use the native transport define by the protocol. I understand you have an application where you want an app server to have access to media services provided by an MG attached through a softswitch. Thats a fine thing to do. I also understand that this requires megaco/MGCP to be used between the app server and the MG, going through the softswitch in order to achieve consistency of control. Now, just because SIP *also* runs between the softswitch and app server, does not mean that if you also need megaco between them, you should tunnel megaco through SIP. Just run megaco as an additional protocol between the two. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jul 9 00:37:03 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14192 for ; Sun, 9 Jul 2000 00:37:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BBF73443AD; Sun, 9 Jul 2000 00:36:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7268344336 for ; Sun, 9 Jul 2000 00:36:49 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22844; Sun, 9 Jul 2000 00:38:18 -0400 (EDT) Message-ID: <39680150.3981E4E4@dynamicsoft.com> Date: Sun, 09 Jul 2000 00:36:32 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Henning Schulzrinne Cc: Brett Tate , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> <39663D1D.B73DB10A@dynamicsoft.com> <396722BB.26C1BF39@cs.columbia.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > My recollection > is that it was difficult to impossible to find somebody that could test > a second media (video) with us, let alone two instances of a media type. Siphone certainly does both. I vaguely remember actually testing this feature with someone at the second bakeoff. In general, setting ports of rejected media streams to 0 is rather trivial by any coding standards and I can't see any reasons for not doing that (except people not being aware that's necessary). --- 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 Sun Jul 9 08:44:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07850 for ; Sun, 9 Jul 2000 08:44:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BBF6744376; Sun, 9 Jul 2000 08:44:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 502B744336 for ; Sun, 9 Jul 2000 08:43:58 -0400 (EDT) Received: (qmail 10181 invoked by uid 1002); 9 Jul 2000 12:42:37 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 9 Jul 2000 15:42:35 +0300 (IDT) To: SIP X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14696.27860.907021.650667@jodie.lucid> Subject: [SIP] Proxying an INVITE-OK Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Following the discussion of proxying BYEs, I now realized that the same problem exists with proxying the OKs of an INVITE. The RFC says that the proxy must proxy the OK, and not ACK it. This is understandble, except that each proxy will repeatedly send the OK until it receives an ACK, or dies out. However - not only can the ACK take some time, it might never reach all the proxies (the ACK might be sent to the Contact, if there is no Record-Route). How is this solved? -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jul 9 16:41:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10549 for ; Sun, 9 Jul 2000 16:41:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2701B44354; Sun, 9 Jul 2000 16:40:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 7F3FB44336 for ; Sun, 9 Jul 2000 16:40:05 -0400 (EDT) Received: (from shbhatna@localhost) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id QAA29854; Sun, 9 Jul 2000 16:39:23 -0400 (EDT) From: Shail Bhatnagar Message-Id: <200007092039.QAA29854@bounty.cisco.com> Subject: Re: [SIP] Proxying an INVITE-OK To: dvir@lucidvon.com (Dvir Oren) Date: Sun, 9 Jul 2000 16:39:23 -0400 (EDT) Cc: sip@lists.bell-labs.com In-Reply-To: <14696.27860.907021.650667@jodie.lucid> from "Dvir Oren" at Jul 09, 2000 03:42:35 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir, 200 response to INVITE is **only** retransmitted (with exponential backoff) by the user agent server. Proxies simply proxy the 200 response to INVITE. > > Following the discussion of proxying BYEs, I now realized that the > same problem exists with proxying the OKs of an INVITE. The RFC says > that the proxy must proxy the OK, and not ACK it. This is > understandble, except that each proxy will repeatedly send the OK > until it receives an ACK, or dies out. However - not only can the ACK > take some time, it might never reach all the proxies (the ACK might be > sent to the Contact, if there is no Record-Route). > > How is this solved? > > -- > Dvir Oren > Lucid VON Ltd. > 9 Saloniki St., Tel-Aviv Israel > Tel: +972 3 644 3038 Fax: +972 3 644 3039 > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jul 9 16:50:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10817 for ; Sun, 9 Jul 2000 16:50:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6130844383; Sun, 9 Jul 2000 16:49:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8504E44353 for ; Sun, 9 Jul 2000 16:49:48 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA00534; Sun, 9 Jul 2000 16:51:06 -0400 (EDT) Message-ID: <3968E548.8CE7D9A5@dynamicsoft.com> Date: Sun, 09 Jul 2000 16:49:12 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Henning Schulzrinne Cc: Brett Tate , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> <39663D1D.B73DB10A@dynamicsoft.com> <396722BB.26C1BF39@cs.columbia.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I think a more interesting question is what to do if you do receive a > new SDP where a media line is "missing" (i.e., the SDP in the 200 has > fewer m= lines than the INVITE) or "misaligned" (e.g., the INVITE has > m=audio,m=video while the 200 has m=video,m=audio). I think it depends on how badly misaligned it is. Following generic "be forgiving on what you receive and strict on what you send" principle, if you can disambiguate the SDP in the response, it's safe to act as if all the necessary m= lines where present. If you can't, you can either take a guess or terminate the call - that should probably be a local decision. But to keep our sanity I'd prohibit any mid-call media renegotiation if one of the parties cannot generate proper SDP. 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 Sun Jul 9 17:18:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11074 for ; Sun, 9 Jul 2000 17:18:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1A16044376; Sun, 9 Jul 2000 17:18:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ns1.comversens.com (ns1.comversens.com [63.64.185.10]) by lists.bell-labs.com (Postfix) with ESMTP id D710744356 for ; Sun, 9 Jul 2000 17:18:17 -0400 (EDT) Received: from mail-bridge.btrd.bostontechnology.com (host.comversens.com [63.64.185.2]) by ns1.comversens.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA12205 for ; Sun, 9 Jul 2000 17:18:47 -0400 (EDT) Received: by mail-bridge.btrd.bostontechnology.com with Internet Mail Service (5.5.2650.21) id <3G4V4JFS>; Sun, 9 Jul 2000 17:18:15 -0400 Message-ID: <35A7D40B978CD311AF05002048404D34024F7C58@wm2.btrd.bostontechnology.com> From: "Shankar, Krishnakumar" To: "'sip@lists.bell-labs.com'" Subject: [SIP] DTMF digit handling Date: Sun, 9 Jul 2000 17:17:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Is there any information available on how DTMF tones/digits are handled in SIP ? More specifically how are DTMF tones/digits sent as part of the RTP media stream over UDP handled reliably. I would like to know is there any other way to receive the DTMF tones at the UAS (user agent server) using SIP. Thanks --Krishna _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 00:47:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16320 for ; Mon, 10 Jul 2000 00:47:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81F214433C; Mon, 10 Jul 2000 00:47:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 718F444336 for ; Mon, 10 Jul 2000 00:47:39 -0400 (EDT) Received: from dynamicsoft.com (1Cust126.tnt1.caldwell.nj.da.uu.net [63.39.178.126]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00843; Mon, 10 Jul 2000 00:48:47 -0400 (EDT) Message-ID: <39695665.8C3F8998@dynamicsoft.com> Date: Mon, 10 Jul 2000 00:51:49 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shankar, Krishnakumar" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: <35A7D40B978CD311AF05002048404D34024F7C58@wm2.btrd.bostontechnology.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Shankar, Krishnakumar" wrote: > > More specifically how are DTMF tones/digits sent as part > of the RTP media stream over UDP handled reliably. They are sent as a special payload format described in RFC2833. > I would like to know is > there any other way to receive the DTMF tones at the UAS (user agent server) > using SIP. In-band RTP is likely to be the preferred way of sending DTMF to a UA. If some of the systems along signaling path are interested in the DTMF, the INFO method may also be used. There are a few ways to encode DTMF in the body of INFO: by using the payload format described in RFC2833, by using MGCP/Megaco packages, etc. --- 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 Mon Jul 10 00:55:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16351 for ; Mon, 10 Jul 2000 00:55:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A8C94436B; Mon, 10 Jul 2000 00:55:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id CD74B44354 for ; Mon, 10 Jul 2000 00:55:17 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id KAA09867; Mon, 10 Jul 2000 10:24:33 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Mon, 10 Jul 2000 10:24:32 +0000 (IST) Received: from pcg142 (pcg142.sasi.com [10.0.64.142]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id KAA27223; Mon, 10 Jul 2000 10:24:29 +0530 (IST) Message-ID: <003f01bfea2a$d62d9220$8e40000a@sasi.com> From: "Krishna G" To: "Shankar, Krishnakumar" Cc: References: <35A7D40B978CD311AF05002048404D34024F7C58@wm2.btrd.bostontechnology.com> Subject: Re: [SIP] DTMF digit handling Date: Mon, 10 Jul 2000 10:23:48 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Krishna, There is lot of information available on the handling of DTMF in SIP. U may want to refer the following internet drafts/RFCs for the information: 1). RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals - RFC 2833 2). Sample Uses of SIP INFO with Varying Reliability Needs - James Kuthan, 3). SIP Info method for DTMF digit transport and collection - Tahsin Chouduri and few other authors from Nortel Networks. 4). SIP Info method for Event Reporting - Bert Culpepper etc. Cheers, Krishna G. Silicon Automation Systems India ----- Original Message ----- From: Shankar, Krishnakumar To: Sent: Monday, July 10, 2000 2:47 AM Subject: [SIP] DTMF digit handling > Hi, > Is there any information available on how DTMF tones/digits are > handled in SIP ? More specifically how are DTMF tones/digits sent as part > of the RTP media stream over UDP handled reliably. I would like to know is > there any other way to receive the DTMF tones at the UAS (user agent server) > using SIP. > > Thanks > --Krishna > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 10 02:27:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29370 for ; Mon, 10 Jul 2000 02:27:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C5314435A; Mon, 10 Jul 2000 02:26:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 45DF544336 for ; Mon, 10 Jul 2000 02:26:03 -0400 (EDT) Received: from dynamicsoft.com (1Cust179.tnt4.freehold.nj.da.uu.net [63.36.112.179]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00970; Mon, 10 Jul 2000 02:27:26 -0400 (EDT) Message-ID: <39696D22.6DBC4B34@dynamicsoft.com> Date: Mon, 10 Jul 2000 02:28:50 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: <35A7D40B978CD311AF05002048404D34024F7C58@wm2.btrd.bostontechnology.com> <39695665.8C3F8998@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > "Shankar, Krishnakumar" wrote: > > > > More specifically how are DTMF tones/digits sent as part > > of the RTP media stream over UDP handled reliably. > > They are sent as a special payload format described in RFC2833. > > > I would like to know is > > there any other way to receive the DTMF tones at the UAS (user agent server) > > using SIP. > > In-band RTP is likely to be the preferred way of sending DTMF to a UA. > If some of the systems along signaling path are interested in the DTMF, > the INFO method may also be used. There are a few ways to encode DTMF in > the body of INFO: by using the payload format described in RFC2833, by > using MGCP/Megaco packages, etc. I should note that this is still an issue of some controversy, both on whether its needed (a UAS will still get the DTMF through RTP), and on how to do it. So, you should not take any of the extensions proposed so far as authoritative or normative. I hope to resolve this at the next meeting. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 02:49:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29626 for ; Mon, 10 Jul 2000 02:49:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5575A44383; Mon, 10 Jul 2000 02:49:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2406C44356 for ; Mon, 10 Jul 2000 02:49:08 -0400 (EDT) Received: from dynamicsoft.com (1Cust179.tnt4.freehold.nj.da.uu.net [63.36.112.179]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA01032; Mon, 10 Jul 2000 02:50:35 -0400 (EDT) Message-ID: <3969728F.5A9281B6@dynamicsoft.com> Date: Mon, 10 Jul 2000 02:51:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sudipto Mukherjee Cc: sip@lists.bell-labs.com Subject: Re: [SIP] QoS and Mid-Session SDP changes References: <3966015F.88D8D11A@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Sudipto Mukherjee wrote: > > Hi, > > RE-INVITEs can change media characteristics such as port, > IP address and codecs, for QoS-Assured Sessions. In this case, > resource reservation needs to be done again with the new media > parameters for the ongoing session. > > The following flow illustrates the above scenario - > > A B > > <-- Active Session with Qos ----> > > > A decides to change media characteristics and sends a > Re-INVITE. > > INV (New SDP A w precondition) > ---------------------------------> > > 183 (SDP B w precondition) > <-------------------------------- > PRACK > --------------------------------> > 200 OK (PRACK) > <------------------------------- > > Reservations successful at A & B > > COMET > ---------------------------------> > 200 OK (COMET) > <-------------------------------- > COMET > <-------------------------------- > 200 OK (COMET) > ---------------------------------> > > 200 OK (SDP B) > <-------------------------------- > ACK > ---------------------------------> > > Session resumes with updated media parameters > > The above flow generates lots of signaling traffic for a > mid-call SDP change. Well, thats the penalty for assured traffic. It is TBD about whether COMET is bidirectional in this and other cases. > > Please comment on the correctness of the flow. Any > suggestions to improve upon, is appreciated. It seems correct, excepting right now there is only a COMET from A to B. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 03:09:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29787 for ; Mon, 10 Jul 2000 03:09:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 91294443E8; Mon, 10 Jul 2000 03:08:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3D4DA44375 for ; Mon, 10 Jul 2000 03:08:41 -0400 (EDT) Received: from dynamicsoft.com (1Cust179.tnt4.freehold.nj.da.uu.net [63.36.112.179]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA01057 for ; Mon, 10 Jul 2000 03:10:11 -0400 (EDT) Message-ID: <39697726.5C11DFCB@dynamicsoft.com> Date: Mon, 10 Jul 2000 03:11:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] agenda items Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Folks, This is a reminder to please send requests for slots at the next SIP wg meeting at the Pittsburgh IETF. Like last time, we suspect to have more requests for time than actual time. So, get your requests in early. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 03: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 ESMTP id DAA00105 for ; Mon, 10 Jul 2000 03:36:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D21444356; Mon, 10 Jul 2000 03:36:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 206AA44336 for ; Mon, 10 Jul 2000 03:36:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6A7aLT28488; Mon, 10 Jul 2000 09:36:36 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA24713; Mon, 10 Jul 2000 10:36:20 +0300 (EET DST) Message-ID: <39697CE5.7A1C2A33@lmf.ericsson.se> Date: Mon, 10 Jul 2000 10:36:05 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Jon.Peterson@Level3.com, sip@lists.bell-labs.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP References: <87A245E94948D3118DE30008C716B01301523A03@c0005v1idc1.oss.level3.com> <3966BDE0.9EE131C7@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, Jonathan Rosenberg wrote: > > Jon.Peterson@Level3.com wrote: > > > > I have a question about the flow below. When C has acquired the provisional > > media (183) SDP from A, is that the time at which C would like to send an > > INVITE to B? Or would C rather wait until someone actually picks up the > > phone at A? Obviously, in a telephone-based service, if A has not yet > > answered when B starts ringing, this could lead to confusion, if the service > > is structured in such a way that the order of operations is important. > > Good observation. > > Interestingly, 3pcc as you have defined (INVITE the 2nd user once the > first answers) and preconditions fundamentally contradict each other. > Preconditions says that you don't send a 200 OK until resources are > reserved; but, you can't reserve resources until you have the address of > the other party with whom you are exchanging media. Getting this address > requires C to send an INVITE to the other party, so it can get back a > 183 with this information. This contradicts the type of 3pcc you desire, > where you don't want to send an INVITE to the the 2nd party until the > first answers with a 200 OK. > > Note that its not sending the INVITE which you really want to avoid, but > you want to make sure one phone rings only after the other has picked > up. This, actually, can be accomplished if we make COMET symmetrical, in > the sense that the caller and called party must both send each other > COMET in order to cause ringing at the other side. WIth this, A and B > will both eventually send COMET to C (note that neither A or B are > ringing). Now, C can send a COMET to A, and then wait for A to answer > the phone (200 OK), before sending a COMET to B. This causes As phone to > ring first, and then Bs phone to ring only after A picks up, as desired. > The reverse can also be accomplished. This allows control of the > ordering of ringing even with preconditions. This is exactly the behavior I am after. > This, however, is not how preconditions work now. Do people believe it > valuable to define such symmetry in order to enable this kind of 3pcc > service? It sounds like a good idea to me. The caller must have the possibility to request COMET from the callee. The previous mode of operation (just COMET from caller to callee) must still be available. I believe that combining 3rd party control and QoS/security preconditions is important. There are some services that need this extension in order to work as it is expected. Gonzalo > > 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: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 06:34:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02364 for ; Mon, 10 Jul 2000 06:34:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 224B64435A; Mon, 10 Jul 2000 06:33:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id CE49A44346 for ; Mon, 10 Jul 2000 06:33:48 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02325; Mon, 10 Jul 2000 06:33:47 -0400 (EDT) Message-Id: <200007101033.GAA02325@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 10 Jul 2000 06:33:47 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-info-method-04.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP INFO Method Author(s) : S. Donovan Filename : draft-ietf-sip-info-method-04.txt Pages : 10 Date : 07-Jul-00 This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP and ISDN signaling messages used to control telephony call services. This and other example uses of the INFO method may be standardized in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-info-method-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-info-method-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-info-method-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: <20000707143922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-info-method-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-info-method-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143922.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 Jul 10 09:43:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08740 for ; Mon, 10 Jul 2000 09:43:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1ACC944356; Mon, 10 Jul 2000 09:43:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 14E2944336 for ; Mon, 10 Jul 2000 09:43:30 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id <3T7J11WC>; Mon, 10 Jul 2000 06:43:28 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" Cc: "'Gethin Liddell'" , sip@lists.bell-labs.com, "'Jonathan Rosenberg'" Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Mon, 10 Jul 2000 06:43:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > Frankly, I thought we solved this problem already several > days ago? Why > invent a kludge that no other URL scheme is using to solve a > non-issue? Henning, I am glad you have so much faith in everybodys' SIP parsers (both existing and future implementations) being able to handle a semicolon in the user part. I, however, am a little more sceptical. Telephone-subscriber is an important feature for parties concerned but IMO it will only be interpreted by a small proportion of the UA's & proxy out there. Frankly, I would prefer that we used recursive escaping of the tel: over your solution. It might be a little more difficult to implement but at least you are not risking interopability with older or simpler SIP parsers. As I said previously (and John reiterated yesterday in another stream) backward compatiability is more important than elegance!! I personally will recommend our gateway does not implement telephone subscriber (as written) because it risks interoperability with many existing UA's (IMO). Regards, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 09:51:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09066 for ; Mon, 10 Jul 2000 09:51:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 48519443E8; Mon, 10 Jul 2000 09:49:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06s.us.nortel.com (unknown [47.140.48.50]) by lists.bell-labs.com (Postfix) with ESMTP id 169E444372 for ; Mon, 10 Jul 2000 09:49:35 -0400 (EDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 10 Jul 2000 09:43:40 -0400 Received: from zrtpd00n.us.nortel.com ([47.156.175.67]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NQCA5Z9B; Mon, 10 Jul 2000 09:43:41 -0400 Received: from americasm01.nt.com (brtpt835.us.nortel.com [47.202.32.90]) by zrtpd00n.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L13J0SDB; Mon, 10 Jul 2000 09:43:36 -0400 Message-ID: <3969D22D.CB448CE5@americasm01.nt.com> Date: Mon, 10 Jul 2000 09:39:57 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Doug Weisenberg" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: <35A7D40B978CD311AF05002048404D34024F7C58@wm2.btrd.bostontechnology.com> <39695665.8C3F8998@dynamicsoft.com> <39696D22.6DBC4B34@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Igor Slepchin wrote: > > > > "Shankar, Krishnakumar" wrote: > > > > > > More specifically how are DTMF tones/digits sent as part > > > of the RTP media stream over UDP handled reliably. > > > > They are sent as a special payload format described in RFC2833. > > > > > I would like to know is > > > there any other way to receive the DTMF tones at the UAS (user agent server) > > > using SIP. > > > > In-band RTP is likely to be the preferred way of sending DTMF to a UA. > > If some of the systems along signaling path are interested in the DTMF, > > the INFO method may also be used. There are a few ways to encode DTMF in > > the body of INFO: by using the payload format described in RFC2833, by > > using MGCP/Megaco packages, etc. > > I should note that this is still an issue of some controversy, both on > whether its needed (a UAS will still get the DTMF through RTP), and on > how to do it. So, you should not take any of the extensions proposed so > far as authoritative or normative. I hope to resolve this at the next > meeting. Given the number of viable mechanisms assuming "its needed", I would guess that Client/Server agreement thru negotiation would be one way to determine "how to do it". Agree? -- Doug > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 09:54:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09154 for ; Mon, 10 Jul 2000 09:54:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94357443EF; Mon, 10 Jul 2000 09:54:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id 9E831443A6 for ; Mon, 10 Jul 2000 09:54:02 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id <3T7J11W8>; Mon, 10 Jul 2000 06:54:02 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Mon, 10 Jul 2000 06:54:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > > In-band RTP is likely to be the preferred way of sending > DTMF to a UA. > > If some of the systems along signaling path are interested > in the DTMF, > > the INFO method may also be used. There are a few ways to > encode DTMF in > > the body of INFO: by using the payload format described in > RFC2833, by > > using MGCP/Megaco packages, etc. > > I should note that this is still an issue of some controversy, both on > whether its needed (a UAS will still get the DTMF through RTP), and on > how to do it. So, you should not take any of the extensions > proposed so > far as authoritative or normative. I hope to resolve this at the next > meeting. Jonathan, I am unsure what issue you beleive needs to be debated. Are you debating the need for a SIP Proxy or User-Agent to receive DTMF digit information (when it is not in the media path); or are you debating that the proposed methods are the wrong way to go about it? Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 10:21:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10073 for ; Mon, 10 Jul 2000 10:21:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E6CA5443ED; Mon, 10 Jul 2000 10:20:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by lists.bell-labs.com (Postfix) with ESMTP id A10F144336 for ; Mon, 10 Jul 2000 10:20:38 -0400 (EDT) Received: from pqm-cons.demon.co.uk ([158.152.93.237] helo=P162U) by anchor-post-30.mail.demon.net with smtp (Exim 2.12 #1) id 13BeQH-00070B-4c; Mon, 10 Jul 2000 15:20:37 +0100 From: "Alex Hardisty" To: "Rohan Mahy" Cc: Subject: RE: [SIP] on directed pick up service Date: Mon, 10 Jul 2000 15:22:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.2.0.58.20000706101059.00cb2f10@lint.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Rohan, Firstly, thanks for your reply ... and thanks also to the other people that replied before. I'm quite new to the IETF way of doing things, although not to Telecoms Standardization. This discussion is therefore quite educational for me. Coming from a background of developing pure telephony services for PBXs and of writing Standards in ECMA for QSIG supplementary services, I do not yet find the IETF approach entirely natural. However, I'm beginning to see some of the benefits it offers. ECMA's approach (please note that I didn't mention ITU-T and H.323) in specifying protocols for QSIG services (such as Call Forwarding and Call Transfer) has been to ensure that only the minimum requirements for achieving multi-vendor interworking are specified, and in such a way that each implementor is free to add value to the service itself as seen by the user. This approach does not appear too different from what IETF does and it is not without its commercial success. It has still proved to be beneficial to spend a little time understanding what the users are going to want to achieve with a particular service or group of services before looking at the existing, established protocol and working out how, if at all, it needs to be extended to support the service(s). In no way does such activity constrain the protocol to only supporting services that we think of or agree to today. Regards -- Alex Hardisty PQM Consultants _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 10:36:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10835 for ; Mon, 10 Jul 2000 10:36:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9A5944419; Mon, 10 Jul 2000 10:34:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8AF9444336 for ; Mon, 10 Jul 2000 10:34:42 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA02463; Mon, 10 Jul 2000 10:35:54 -0400 (EDT) Message-ID: <3969DFA4.3E2D228A@dynamicsoft.com> Date: Mon, 10 Jul 2000 10:37:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > > > In-band RTP is likely to be the preferred way of sending > > DTMF to a UA. > > > If some of the systems along signaling path are interested > > in the DTMF, > > > the INFO method may also be used. There are a few ways to > > encode DTMF in > > > the body of INFO: by using the payload format described in > > RFC2833, by > > > using MGCP/Megaco packages, etc. > > > > I should note that this is still an issue of some controversy, both on > > whether its needed (a UAS will still get the DTMF through RTP), and on > > how to do it. So, you should not take any of the extensions > > proposed so > > far as authoritative or normative. I hope to resolve this at the next > > meeting. > > Jonathan, I am unsure what issue you beleive needs to be debated. Are you > debating the need for a SIP Proxy or User-Agent to receive DTMF digit > information (when it is not in the media path); or are you debating that the > proposed methods are the wrong way to go about it? Both. So far pretty much every application requiring DTMF was for a device that was a user agent and media termination point, so sending it in SIP seems redundant. These kinds of applications include IVR, pre-paid billing, credit card collection, etc. For those applications where the application resides on a device that is not a media termination point, the device has always appeared to be a SIP user agent (typically doing things like 3pcc). In this case, I would argue along the lines that Scott Petrack has been arguing - the right way to handle these is to allow the UA to insert a field into SDP that allows it to get RTP but only RTP with the DTMF codec. This allows it to get DTMF, but not see "all" the media otherwise. Note that I am still cautious about these kinds of things. They basically imply that providing the service *relies* on the origination point correctly doing DTMF. There is such a wide range of access devices supporting SIP; counting on each and every one of them everywhere always performing DTMF correctly seems dangerous. So, the safe way to get the DTMF is to terminate the entire media stream, so that you can do your own detection if needed.. In any case, most DTMF-based apps often also allow for speech recognition, which requires termination of the media stream at the application point anyway. As for the current proposals, I think most also include a control component that allows the proxy/app server to tell the UA things like what digit mask to use. These are completely inappropriate in SIP. THey rule out the possibility of multiple application servers handling a call, and they also imply a trust relationship between the app server and the originator, which may not always exist. SIP is a poor control protocol, primarily because of its distributed nature. If we were to do DTMF over SIP itself, it would have to be restricted to just the mechanism for encapsulating the digits in SIP messages, thats it. If you NEED more control than that for your application, well, sounds like it might be more suitable to user megaco. See another thread on this subject recently on the list.... -Jonathan R. > > Robert. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 10:40:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10929 for ; Mon, 10 Jul 2000 10:40:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 652F34441E; Mon, 10 Jul 2000 10:36:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8CB9944413 for ; Mon, 10 Jul 2000 10:36:06 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA02491; Mon, 10 Jul 2000 10:37:11 -0400 (EDT) Message-ID: <3969DFF0.D6FC247F@dynamicsoft.com> Date: Mon, 10 Jul 2000 10:38:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Weisenberg Cc: Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: <35A7D40B978CD311AF05002048404D34024F7C58@wm2.btrd.bostontechnology.com> <39695665.8C3F8998@dynamicsoft.com> <39696D22.6DBC4B34@dynamicsoft.com> <3969D22D.CB448CE5@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Doug Weisenberg wrote: > > > I should note that this is still an issue of some controversy, both on > > whether its needed (a UAS will still get the DTMF through RTP), and on > > how to do it. So, you should not take any of the extensions proposed so > > far as authoritative or normative. I hope to resolve this at the next > > meeting. > > Given the number of viable mechanisms assuming "its needed", I would > guess that Client/Server agreement thru negotiation would be one way to > determine "how to do it". Agree? No. If we do it, we will pick a single protocol extension for it, thats 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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 11: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 ESMTP id LAA13765 for ; Mon, 10 Jul 2000 11:42:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 39B854438A; Mon, 10 Jul 2000 11:41:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id BBB1C44336 for ; Mon, 10 Jul 2000 11:41:28 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA28235; Mon, 10 Jul 2000 08:41:33 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11275; Mon, 10 Jul 2000 08:41:24 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14697.61092.158764.32643@thomasm-u1.cisco.com> Date: Mon, 10 Jul 2000 08:41:24 -0700 (PDT) To: Jonathan Rosenberg Cc: Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling In-Reply-To: <39696D22.6DBC4B34@dynamicsoft.com> References: <35A7D40B978CD311AF05002048404D34024F7C58@wm2.btrd.bostontechnology.com> <39695665.8C3F8998@dynamicsoft.com> <39696D22.6DBC4B34@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > If some of the systems along signaling path are interested in the DTMF, > > the INFO method may also be used. There are a few ways to encode DTMF in > > the body of INFO: by using the payload format described in RFC2833, Yuck. > > by > > using MGCP/Megaco packages, etc. Double Yuck. Why is it so difficult to just receive RFC2833 payloads over RFC 1889 transport? Jonathan Rosenberg writes: > I should note that this is still an issue of some controversy, both on > whether its needed (a UAS will still get the DTMF through RTP), and on > how to do it. So, you should not take any of the extensions proposed so > far as authoritative or normative. I hope to resolve this at the next > meeting. In the last go-round of this perennial merry-go-round, the main complaint I heard is that interior IVR's might not have the MIPS/whatever to do DTMF detection and that they'd like to have the originator -- who has to have a DTMF detector anyway -- do the DSP kruft. Fine. We now have RFC 2833. Trying to thread this back through SIP, however, seems like a really bad idea though: why not just use SIP to transport RTP itself? And putting MGCP/MEGACO into SIP body headers is a gruesome layer violation... it's sort of like the protocol equivalent of an inter-subroutine goto with none of the careful rationalizations of setjmp/longjmp. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 11:54:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14261 for ; Mon, 10 Jul 2000 11:54:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 569DC44402; Mon, 10 Jul 2000 11:53:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 8B74744336 for ; Mon, 10 Jul 2000 11:53:52 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA08980; Mon, 10 Jul 2000 08:53:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11278; Mon, 10 Jul 2000 08:53:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14697.61838.962101.581067@thomasm-u1.cisco.com> Date: Mon, 10 Jul 2000 08:53:50 -0700 (PDT) To: Jonathan Rosenberg Cc: "Fairlie-Cuninghame, Robert" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling In-Reply-To: <3969DFA4.3E2D228A@dynamicsoft.com> References: <3969DFA4.3E2D228A@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > Note that I am still cautious about these kinds of things. They > basically imply that providing the service *relies* on the origination > point correctly doing DTMF. There is such a wide range of access devices > supporting SIP; counting on each and every one of them everywhere always > performing DTMF correctly seems dangerous. So, the safe way to get the > DTMF is to terminate the entire media stream, so that you can do your > own detection if needed.. In any case, most DTMF-based apps often also > allow for speech recognition, which requires termination of the media > stream at the application point anyway. I guess I'm not as worried here: if you're using a codec which isn't good at transporting DTMF like G.723 or G.729, you have pretty good incentive to get your DTMF codec ala RFC2833 correct. Also: things like IP phones or PC's don't need DTMF detectors for local digit collection at all. If the far end wants to see DTMF for an IVR, say, the phone is going to have to manufacture DTMF anyway. If anything, I'd expect that the likelihood of getting NSE's correct is a lot higher than injecting DTMF waveforms into a G.711 stream... Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 11:57:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14337 for ; Mon, 10 Jul 2000 11:57:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9688144415; Mon, 10 Jul 2000 11:57:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 21DF044410 for ; Mon, 10 Jul 2000 11:57:07 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA00958; Mon, 10 Jul 2000 11:57:06 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA25487; Mon, 10 Jul 2000 11:57:06 -0400 (EDT) Message-ID: <3969F251.F5B56845@cs.columbia.edu> Date: Mon, 10 Jul 2000 11:57:05 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'Gethin Liddell'" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP URL telephone-subscriber syntax. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > > Frankly, I thought we solved this problem already several > > days ago? Why > > invent a kludge that no other URL scheme is using to solve a > > non-issue? > > Henning, > > I am glad you have so much faith in everybodys' SIP parsers (both existing > and future implementations) being able to handle a semicolon in the user > part. I, however, am a little more sceptical. Telephone-subscriber is an > important feature for parties concerned but IMO it will only be interpreted > by a small proportion of the UA's & proxy out there. > > Frankly, I would prefer that we used recursive escaping of the tel: over > your solution. It might be a little more difficult to implement but at least > you are not risking interopability with older or simpler SIP parsers. As I > said previously (and John reiterated yesterday in another stream) backward > compatiability is more important than elegance!! I personally will recommend > our gateway does not implement telephone subscriber (as written) because it > risks interoperability with many existing UA's (IMO). I'm disappointed that Nuera decides to go against community consensus and the spec [assuming it does not agree with your position at the moment]. I hope that you are not representing the official position of Nuera. Bake-offs are designed to test appropriate implementation behavior and discover whether there is a widespread compatibility issue. We should make sure that this is included in the bake-off agenda. (Judging from the last bake-off, this was, in general, a feature that needed more implementor attention, regardless of the semicolon issue.) > > Regards, > > Robert. -- 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 Jul 10 12: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 ESMTP id MAA15135 for ; Mon, 10 Jul 2000 12:15:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 428A74439E; Mon, 10 Jul 2000 12:15:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pop-rocks.shoretel.com (pop-rocks.shoretel.com [208.163.34.3]) by lists.bell-labs.com (Postfix) with ESMTP id A9D4C44346 for ; Mon, 10 Jul 2000 12:14:57 -0400 (EDT) Received: by pop-rocks.shoretel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 09:10:27 -0700 Message-ID: From: Dale Tonogai To: "'Jonathan Rosenberg'" , Jo Hornsby Cc: Krishna G , sip@lists.bell-labs.com Subject: RE: [SIP] on directed pick up service Date: Mon, 10 Jul 2000 09:10:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have a couple of questions on how this would work. (1) How does the user agent know that the subsequent INVITE that it receives is for the call that is being picked up? I suppose you could look at the To header, but the information may not be useful if the call had already been forwarded. (2) It seems a little odd that the user agent has to be ready to receive the INVITE for the picked up call even before it knows that its REGISTER request was successful. Since the REGISTER response could get lost, the INVITE could arrive before the REGISTER transaction was completed. Dale > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 05, 2000 9:17 PM > To: Jo Hornsby > Cc: Krishna G; sip@lists.bell-labs.com > Subject: Re: [SIP] on directed pick up service > > > > > Jo Hornsby wrote: > > > > > > Basically, a typical call flow for such a scenario would be: > > > > > > > > A --INVITE--> P B --INVITE--> C > > > > --INVITE--> > > > > <---180---- > > > > <--RINGING- > > > > (At this point, User 2 hears B ringing from C) > > > > <--------REGISTER-------- > > > > -----------200----------> > > > > ----------INVITE--------> > > > > <--------RINGING--------- > > > > <----------200----------- > > > > --CANCEL--> > > > > (yada yada) > > > > > > > > (In the above case, P is a forking proxy that CANCELs pending > > > > branches upon reception of a 200 response, and which > also acts as > > > > a Registrar.) > > > > > > *** Now how does C know that it has to send the REGISTER > request to P? > > > > Blind faith. &:) > > > > But seriously, this is where things potentially break-down, or not. > > Something like "Directed Pick-Up" (if indeed that is the correct > > term) does require some sort of sane configuration/application. > > How is it done in the circuit switched world? After all, both phones > need to be part of the same PBX for this to work. Well, both terminals > are hard wired to the same PBX. You can think of that as the > ultimate in > hardcoded configuration. The same is true here. As Jo has correctly > pointed out, the service works assuming that both phones are > configured > to use the same proxy server. > > Alex Hardisty writes: > > 2) Directed call pick-up requires me to enter the number of > the telephone > > that is ringing, so am I entering the number of the UA or > am I entering my > > personal number? If the latter it's not Directed Call > Pickup but Personal > > User Mobility. What's the service definition here? > > The service definition is whatever you want it to be. We here at IETF > don't specify services, but rather protocols to support services. > > If the service you want is something as close as possible to existing > call pickup, you can do that. A terminal is typically > associated with a > number, and would register itself as the handler for that number: > > REGISTER sip:example.com SIP/2.0 > To: sip:1234@example.com > Contact: sip:1234@phone23827304-8762.example.com > > The phone for extension 4321 would normally send a similar > registration: > > REGISTER sip:example.com SIP/2.0 > To: sip:4321@example.com > Contact: sip:4321@phone11223344556677.example.com > > when I am sitting at extension 4321, and hear 1234 ringing, > and want to > pick it up, I would dial the appropriate service code and > then enter the > extension I want to pick up. This would cause that phone to send an > additional register: > > REGISTER sip:example.com SIP/2.0 > To: sip:1234@example.com > Contact: sip:4321@phone11223344556677.example.com > > Now, this terminal begins to ring also and I can pick it up. > > > Note that the "smarts" for this service are actually distributed; some > of it is in the UA (which needs to know to send registers > formatted this > way when implementing the directed pickup service), and some in the > proxy (which is doing normal registrations). > > > > One point I neglected to mention before was that this isn't > > exactly the same as "Directed Pick-Up" (in my experience of the > > term), anyway. P may send an additional INVITE to C, but that > > doesn't mean that B stops ringing (indeed, I can imagine > > situations where that would be completely undesirable -- > > preemptively registering a holiday address, for example -- since > > User 2's call would suddenly "disappear"). It's only once User 2 > > picks up from C, that B _might_ stop ringing. > > Correct. Note however, that causing the original terminal to stop > ringing can > also be achieved with some additional smarts in the phones, sending an > additional REGISTER to unregister the original address... > > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 12:23:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15646 for ; Mon, 10 Jul 2000 12:23:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B2EB44413; Mon, 10 Jul 2000 12:23:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lists.bell-labs.com (Postfix) with SMTP id 0A128443ED for ; Mon, 10 Jul 2000 12:23:37 -0400 (EDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Jul 2000 09:23:18 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Mon, 10 Jul 2000 09:23:17 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01FF5823@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Henry Sinnreich'" , Michael Thomas , "Culpepper, Bert" Cc: "Gardell, Steve" , "'Jonathan Rosenberg'" , Serban Tatu , siplist Subject: RE: [SIP] authentication at gateway Date: Mon, 10 Jul 2000 09:23:14 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > From: Henry Sinnreich [mailto:Henry.Sinnreich@WCom.com] > > SIP is great and all, but IP seems like a much > > more efficient transport for MGCP/MEGACO. > I understand MGCP/MEGACO needs SCTP for reliable transport > across the net. Not that I think it is good idea, since you end > up with a MGCP/MEGACO network under GC control instead of the > open Internet. Uh? Megaco has been toying with SCTP, but MGCP is definitely designed to run over UDP, using timers, etc. that behave just like those in SIP. AFAIK UDP is also an authorized transport for Megaco. OTOH, MGCP was definitely not design as an "open Internet" or "end to end" protocol. It is a client-server protocol, and third parties are expected to only see the gateway, which is the client, through the call agent, which is the server. MGCP was carefully designed to integrate well with SIP; the idea of transporting MGCP data over SIP is nonsense. Christian Huitema _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 13:12:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17739 for ; Mon, 10 Jul 2000 13:12:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF9A54443D; Mon, 10 Jul 2000 13:11:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchangesvr.nuera.com (unknown [204.216.240.124]) by lists.bell-labs.com (Postfix) with ESMTP id B541B44346 for ; Mon, 10 Jul 2000 13:11:21 -0400 (EDT) Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id <3T7J1FLH>; Mon, 10 Jul 2000 10:11:21 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning Schulzrinne'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Date: Mon, 10 Jul 2000 10:11:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi Henning, > I'm disappointed that Nuera decides to go against community consensus > and the spec [assuming it does not agree with your position at the > moment]. I hope that you are not representing the official position of > Nuera. Looks like I should put one of those "My opinions are not necessarily those of my employers" disclaimers at the bottom of my emails. I am only the janitor here . Come one, there is no "community" consensus here yet (let alone a published "spec" as you say) and that what is being proposed is something that is _not_ backward compatible (and you don't need a bakeoff to see it). Doesn't that count for anything? What about the cries for backward compatibility over elegance? I would say this is a prime example. My only goal is to get a usable telephone-subscriber syntax where there are no fears that someone using plain old RFC2543 (or an earlier bis version) will not reject the message because of the semicolon in the user part (which is a definite concern in my mind). Robert. My opinions are not those of the company owning the domain www.nuera.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 Jul 10 13:19:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18170 for ; Mon, 10 Jul 2000 13:19:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 63A0B44452; Mon, 10 Jul 2000 13:19:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by lists.bell-labs.com (Postfix) with ESMTP id 867A44443A for ; Mon, 10 Jul 2000 13:19:14 -0400 (EDT) Received: from MATT.ascend.com (ts006d33.lap-ca.concentric.net [64.1.209.45]) by sheffield.cnchost.com id NAA15881; Mon, 10 Jul 2000 13:19:02 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-Id: <4.3.1.2.20000710092506.00b886f0@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 10 Jul 2000 09:28:22 -0700 To: "Fairlie-Cuninghame, Robert" From: Matt Holdrege Subject: RE: [SIP] SIP URL telephone-subscriber syntax. Cc: sip@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com At 06:43 AM 7/10/00 -0700, Fairlie-Cuninghame, Robert wrote: >I am glad you have so much faith in everybodys' SIP parsers (both existing >and future implementations) being able to handle a semicolon in the user >part. I, however, am a little more sceptical. Telephone-subscriber is an >important feature for parties concerned but IMO it will only be interpreted >by a small proportion of the UA's & proxy out there. > >Frankly, I would prefer that we used recursive escaping of the tel: over >your solution. It might be a little more difficult to implement but at least >you are not risking interopability with older or simpler SIP parsers. As I >said previously (and John reiterated yesterday in another stream) backward >compatiability is more important than elegance!! I personally will recommend >our gateway does not implement telephone subscriber (as written) because it >risks interoperability with many existing UA's (IMO). Please take a step back and look at SIP in a larger case context. How can we worry about backwards compatibility with something that doesn't yet exist? There is more to SIP's future than what early adopter engineers have to deal with. Isn't it worth a small amount of hassle to provide a good working long lasting protocol? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 14:54:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23156 for ; Mon, 10 Jul 2000 14:54:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A2BF4443C4; Mon, 10 Jul 2000 14:53:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 5833144343 for ; Mon, 10 Jul 2000 14:52:59 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0FXH00201WG7V3@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 10 Jul 2000 18:52:55 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FXH0015QWG7JV@firewall.mcit.com>; Mon, 10 Jul 2000 18:52:55 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0FXH00E01WG6T6@pmismtp01.wcomnet.com>; Mon, 10 Jul 2000 18:52:55 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FXH00E01WG2S7@pmismtp01.wcomnet.com>; Mon, 10 Jul 2000 18:52:54 +0000 (GMT) Received: from C25776A ([166.35.227.169]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FXH009O3WFED2@pmismtp01.wcomnet.com>; Mon, 10 Jul 2000 18:52:39 +0000 (GMT) Date: Mon, 10 Jul 2000 13:52:37 -0500 From: Henry Sinnreich Subject: RE: [SIP] DTMF digit handling In-reply-to: <003f01bfea2a$d62d9220$8e40000a@sasi.com> To: Jonathan Rosenberg DynamicSoft , "Shankar, Krishnakumar" , Krishna G Cc: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Yes, the attached are good pointers, but it seems a DTMF-SIP framework document is required to tie all this info together. Any volunteers? Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Krishna G >Sent: Sunday, July 09, 2000 11:54 PM >To: Shankar, Krishnakumar >Cc: sip@lists.bell-labs.com >Subject: Re: [SIP] DTMF digit handling > > >Hi Krishna, > > There is lot of information available on the >handling of DTMF in SIP. U >may want to refer the following internet drafts/RFCs >for the information: >1). RTP Payload for DTMF Digits, Telephony Tones and >Telephony Signals - RFC >2833 >2). Sample Uses of SIP INFO with Varying Reliability >Needs - James Kuthan, >3). SIP Info method for DTMF digit transport and >collection - Tahsin >Chouduri and few other authors from Nortel Networks. >4). SIP Info method for Event Reporting - Bert Culpepper etc. > >Cheers, > >Krishna G. >Silicon Automation Systems >India From: sip-admin@lists.bell-labs.com on behalf of Jonathan Rosenberg [jdrosen@dynamicsoft.com] Sent: Monday, July 10, 2000 1:29 AM To: Igor Slepchin Cc: Shankar, Krishnakumar; 'sip@lists.bell-labs.com' Subject: Re: [SIP] DTMF digit handling Igor Slepchin wrote: > > "Shankar, Krishnakumar" wrote: > > > > More specifically how are DTMF tones/digits sent as part > > of the RTP media stream over UDP handled reliably. > > They are sent as a special payload format described in RFC2833. > > > I would like to know is > > there any other way to receive the DTMF tones at the UAS (user agent server) > > using SIP. > > In-band RTP is likely to be the preferred way of sending DTMF to a UA. > If some of the systems along signaling path are interested in the DTMF, > the INFO method may also be used. There are a few ways to encode DTMF in > the body of INFO: by using the payload format described in RFC2833, by > using MGCP/Megaco packages, etc. I should note that this is still an issue of some controversy, both on whether its needed (a UAS will still get the DTMF through RTP), and on how to do it. So, you should not take any of the extensions proposed so far as authoritative or normative. I hope to resolve this at the next meeting. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip >----- Original Message ----- >From: Shankar, Krishnakumar >To: >Sent: Monday, July 10, 2000 2:47 AM >Subject: [SIP] DTMF digit handling > > >> Hi, >> Is there any information available on how DTMF >tones/digits are >> handled in SIP ? More specifically how are DTMF >tones/digits sent as part >> of the RTP media stream over UDP handled reliably. I >would like to know is >> there any other way to receive the DTMF tones at the >UAS (user agent >server) >> using SIP. >> >> Thanks >> --Krishna >> >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/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 Jul 10 15: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 ESMTP id PAA24666 for ; Mon, 10 Jul 2000 15:21:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 24BB84440B; Mon, 10 Jul 2000 15:20:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6ED2144343 for ; Mon, 10 Jul 2000 15:20:47 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA11973; Mon, 10 Jul 2000 15:20:46 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA01548; Mon, 10 Jul 2000 15:20:46 -0400 (EDT) Message-ID: <396A220E.B25AEB99@cs.columbia.edu> Date: Mon, 10 Jul 2000 15:20:46 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Brett Tate , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> <39663D1D.B73DB10A@dynamicsoft.com> <396722BB.26C1BF39@cs.columbia.edu> <3968E548.8CE7D9A5@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > Henning Schulzrinne wrote: > > > > I think a more interesting question is what to do if you do receive a > > new SDP where a media line is "missing" (i.e., the SDP in the 200 has > > fewer m= lines than the INVITE) or "misaligned" (e.g., the INVITE has > > m=audio,m=video while the 200 has m=video,m=audio). > > I think it depends on how badly misaligned it is. Following generic "be > forgiving on what you receive and strict on what you send" principle, if > you can disambiguate the SDP in the response, it's safe to act as if all > the necessary m= lines where present. If you can't, you can either take > a guess or terminate the call - that should probably be a local > decision. But to keep our sanity I'd prohibit any mid-call media > renegotiation if one of the parties cannot generate proper SDP. If all else fails, a robust application can simply restart applications if it gets a new SDP in an INVITE that doesn't line up with an earlier SDP. This is needed in any event for the "other side crashed" case, since the crashed entity may not know about old media streams. (It should obviously still send a zero-port in the response for the media entries it doesn't want.) I suspect that this is how most (more sophisticated) implementations will behave in any event on receiving an INVITE: look up existing media streams (by type, address/port and position in description) and modify local sending applications accordingly. If I get an INVITE with a new ``m='' line that doesn't correspond to any media stream, I need to start a new one. -- 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 Jul 10 15:23:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24793 for ; Mon, 10 Jul 2000 15:23:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0518044424; Mon, 10 Jul 2000 15:23:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 14A9D44417 for ; Mon, 10 Jul 2000 15:23:04 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA10086; Mon, 10 Jul 2000 15:19:16 -0400 (EDT) Message-ID: <396A21B4.639C5AFF@cisco.com> Date: Mon, 10 Jul 2000 15:19:16 -0400 From: Manoj Bhatia Organization: Cisco Systems, RTP, NC, USA. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: A Srinath , sip@lists.bell-labs.com Subject: Re: [SIP] Differant URL's in headers References: <003c01bfe825$7d236990$4e34c3c1@ubiquity.co.uk> Content-Type: multipart/alternative; boundary="------------72B4E4D3C593A3538E606726" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------72B4E4D3C593A3538E606726 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Srinath Once outside SIP URLs, things have not been defined in detail so far. Currenlty, only SIP URLs and Tel (telephony based) URLs are some of the accepted semantics that are being worked out. Any implementations /testbeds where sip and non-sip urls are being tested together ? thanks -manoj Jo Hornsby wrote: > > I have a query regarding URLs of other schemes in the headers. > > > > 1. How does a user agent client send an INVITE to a TO conatianing, > > say a mailto URL or even an HTTP URL. What will be the Request-URI > > then. > > Well, I would typically expect the Request-URI to (initially) be the > same as the To, as specified by Section 11.1. However, I think it is > reasonable to say that for schemes such as mailto:, the intent > is not obvious -- are you intending to set up a mail session; what > does this mean? > > In the end, it's going to require User Agents that understand the > semantics of these non-SIP URL URIs, and perhaps any proxies > along the path to understand, too (proxies are required to return > 400 if they don't understand the scheme in the Request-URI). If > you want "normal" SIP-routing on an unknown SIP "network" with > a non-SIP URI, then the UAs/edge-proxies are going to have to do > something clever like encoding the "real" Request-URI into a > SIP URL-compatible form, or perhaps just rely on the To being > honoured (completely reasonable for a UAS), and set the Request-URI > to some sort of "pseudo" SIP URL that will make it likely the > Request gets to the right place. > > I think section 4.3 (in the bis) has the best explanation of typical > behaviour; of course, once outsida SIP URLs, things are a little > more atypical. > > Cheers, > > - Jo. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, P.O. Box 14987 | :|||||: :|||||: Research Triangle Park, NC 27709 | .:|||||||:.:|||||||:. 919-392-3873 fax: 919-392-6801 | C i s c o S y s t e m s --------------72B4E4D3C593A3538E606726 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Srinath

Once outside SIP URLs, things have not been defined in detail so far.
Currenlty, only SIP URLs and Tel (telephony based) URLs are some of
the accepted semantics that are being worked out.

Any implementations /testbeds where sip and non-sip urls are being
tested together ?

thanks
-manoj
Jo Hornsby wrote:

>       I have a query regarding URLs of other schemes in the headers.
>
> 1. How does a user agent client send an INVITE to a TO conatianing,
> say a mailto URL or even an HTTP URL. What will be the Request-URI
> then.

Well, I would typically expect the Request-URI to (initially) be the
same as the To, as specified by Section 11.1.  However, I think it is
reasonable to say that for schemes such as mailto:, the intent
is not obvious -- are you intending to set up a mail session; what
does this mean?

In the end, it's going to require User Agents that understand the
semantics of these non-SIP URL URIs, and perhaps any proxies
along the path to understand, too (proxies are required to return
400 if they don't understand the scheme in the Request-URI).  If
you want "normal" SIP-routing on an unknown SIP "network" with
a non-SIP URI, then the UAs/edge-proxies are going to have to do
something clever like encoding the "real" Request-URI into a
SIP URL-compatible form, or perhaps just rely on the To being
honoured (completely reasonable for a UAS), and set the Request-URI
to some sort of "pseudo" SIP URL that will make it likely the
Request gets to the right place.

I think section 4.3 (in the bis) has the best explanation of typical
behaviour; of course, once outsida SIP URLs, things are a little
more atypical.

Cheers,

 - Jo.

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

-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, P.O. Box 14987    |     :|||||:   :|||||:
Research Triangle Park, NC 27709       |   .:|||||||:.:|||||||:.
919-392-3873      fax: 919-392-6801    |  C i s c o S y s t e m s
  --------------72B4E4D3C593A3538E606726-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 15:25:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24872 for ; Mon, 10 Jul 2000 15:25:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81082443AB; Mon, 10 Jul 2000 15:23:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 0C99E4438D for ; Mon, 10 Jul 2000 15:23:12 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id OAA22451; Mon, 10 Jul 2000 14:24:32 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jul 2000 14:18:57 -0500 Message-ID: From: "Culpepper, Bert" To: Michael Thomas , Jonathan Rosenberg Cc: Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Mon, 10 Jul 2000 14:18:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, July 10, 2000 11:41 AM > To: Jonathan Rosenberg > Cc: Igor Slepchin; Shankar, Krishnakumar; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DTMF digit handling > > > > Igor Slepchin wrote: > > > If some of the systems along signaling path are interested in the DTMF, > > > the INFO method may also be used. There are a few ways to encode DTMF in > > > the body of INFO: by using the payload format described in RFC2833, > > Yuck. > > > > by > > > using MGCP/Megaco packages, etc. > > Double Yuck. > > Why is it so difficult to just receive RFC2833 payloads > over RFC 1889 transport? > As I understand RTP, there is no guaranteed deliver of RTP packets. Therefor, the need for a reliable protocol. Also, requiring a 3rd party platform to process the media adds delay when it is in the middle of a session between two other endpoints. > Jonathan Rosenberg writes: > > I should note that this is still an issue of some controversy, both on > > whether its needed (a UAS will still get the DTMF through RTP), and on > > how to do it. So, you should not take any of the extensions proposed so > > far as authoritative or normative. I hope to resolve this at the next > > meeting. > > In the last go-round of this perennial merry-go-round, > the main complaint I heard is that interior IVR's might > not have the MIPS/whatever to do DTMF detection and that > they'd like to have the originator -- who has to have > a DTMF detector anyway -- do the DSP kruft. Fine. We now > have RFC 2833. Trying to thread this back through SIP, > however, seems like a really bad idea though: why not > just use SIP to transport RTP itself? And putting > MGCP/MEGACO into SIP body headers is a gruesome > layer violation... it's sort of like the > protocol equivalent of an inter-subroutine goto > with none of the careful rationalizations of > setjmp/longjmp. > > Mike > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 10 15:41:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25749 for ; Mon, 10 Jul 2000 15:41:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 84E4C443A4; Mon, 10 Jul 2000 15:38:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 6B5C144343 for ; Mon, 10 Jul 2000 15:38:44 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id OAA22600; Mon, 10 Jul 2000 14:35:58 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jul 2000 14:30:38 -0500 Message-ID: From: "Culpepper, Bert" To: Michael Thomas , Jonathan Rosenberg Cc: "Fairlie-Cuninghame, Robert" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Mon, 10 Jul 2000 14:30:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, July 10, 2000 11:54 AM > To: Jonathan Rosenberg > Cc: Fairlie-Cuninghame, Robert; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DTMF digit handling > > > Jonathan Rosenberg writes: > > Note that I am still cautious about these kinds of things. They > > basically imply that providing the service *relies* on the origination > > point correctly doing DTMF. There is such a wide range of access devices > > supporting SIP; counting on each and every one of them everywhere always > > performing DTMF correctly seems dangerous. So, the safe way to get the > > DTMF is to terminate the entire media stream, so that you can do your > > own detection if needed.. In any case, most DTMF-based apps often also > > allow for speech recognition, which requires termination of the media > > stream at the application point anyway. > > I guess I'm not as worried here: if you're using > a codec which isn't good at transporting DTMF like > G.723 or G.729, you have pretty good incentive to > get your DTMF codec ala RFC2833 correct. Also: things > like IP phones or PC's don't need DTMF detectors > for local digit collection at all. If the far > end wants to see DTMF for an IVR, say, the > phone is going to have to manufacture DTMF > anyway. If anything, I'd expect that the > likelihood of getting NSE's correct is a lot > higher than injecting DTMF waveforms into a > G.711 stream... > > Mike > RFC2833 solves distortion issues with low bit-rate codecs. And I, myself don't see the use of DTMF with IP Phones or PCs. Where I see DTMF in a SIP network is when SIP (and RTP) carries PSTN traffic. We can either support the existing services (and new services possible with IP networks) offered by telecommunications service providers or tell them SIP in part of their network won't work if they are not willing to accept the loss of voice quality and some existing service features. However, no extensions to SIP or the media gateway control protocol are needed if service deployment is limited to the call agent on the gateway controller, no loss of voice quality occurs and any existing service I can think of can be provided unchanged. Let's rule out 3rd-party call control and the issue goes away :). > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 10 15:46:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25970 for ; Mon, 10 Jul 2000 15:46:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B155444457; Mon, 10 Jul 2000 15:43:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 64A2A443E3 for ; Mon, 10 Jul 2000 15:43:16 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA16482; Mon, 10 Jul 2000 15:43:15 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA02309; Mon, 10 Jul 2000 15:43:14 -0400 (EDT) Message-ID: <396A2752.AC586E0C@cs.columbia.edu> Date: Mon, 10 Jul 2000 15:43:14 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: Michael Thomas , Jonathan Rosenberg , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Culpepper, Bert" wrote: > > > As I understand RTP, there is no guaranteed deliver of RTP packets. > Therefor, the need for a reliable protocol. Also, requiring a 3rd party > platform to process the media adds delay when it is in the middle > of a session between two other endpoints. > > We've had this discussion a few times in the last few years, but this seems to be a recurring misperception. DTMF-over-RTP is roughly as reliable as any UDP or TCP-based protocol. All three, SIP-over-UDP, RFC 2833 and SIP-over-TCP, rely on retransmission (ACK-based or "FEC"-based), just at different layer. All can fail, eventually, if too many packets are lost in a row. (TCP will retranmsmit for a long time, but it is not clear whether receiving a DTMF digit an hour or even thirty seconds after the key was pressed is very useful. You probably need to have an application-layer timeout in any event, as in "sorry, your number is incomplete, please redial".) In most cases, RTP-based retransmission is much faster than TCP-based retransmission, in line with the real-time requirements of outbound PSTN gateways. Besides, as discussed here a few times, if you prefer the TCP model of reliability, you can carry RTP in TCP. The delay issue is also bogus, since you can forward the voice packet even before you do the analysis (unless you need to synchronize tones and audio at the outbound IP-to-PSTN gateway, but then SIP or anything else that doesn't have precise timing information isn't going to help you.) -- 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 Jul 10 15:50:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26253 for ; Mon, 10 Jul 2000 15:50:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C6AB44422; Mon, 10 Jul 2000 15:48:23 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by lists.bell-labs.com (Postfix) with ESMTP id 230F7443EC for ; Mon, 10 Jul 2000 15:48:20 -0400 (EDT) Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id PAA22048; Mon, 10 Jul 2000 15:48:45 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA16718; Tue, 11 Jul 2000 00:48:18 +0500 Message-Id: <200007101948.AAA16718@hafez.east.isi.edu> To: "Culpepper, Bert" Cc: Michael Thomas , Jonathan Rosenberg , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling In-Reply-To: Your message of "Mon, 10 Jul 2000 14:18:54 CDT." Date: Mon, 10 Jul 2000 15:48:18 -0400 From: Colin Perkins Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --> "Culpepper, Bert" writes: >As I understand RTP, there is no guaranteed deliver of RTP packets. >Therefor, the need for a reliable protocol. Also, requiring a 3rd party >platform to process the media adds delay when it is in the middle >of a session between two other endpoints. RFC 2833 allows for a redundant transmission mechanism, to achieve very effective loss resilience... Colin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 15:57:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26395 for ; Mon, 10 Jul 2000 15:57:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B99A44383; Mon, 10 Jul 2000 15:56:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 0554044339 for ; Mon, 10 Jul 2000 15:56:21 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA28779; Mon, 10 Jul 2000 21:55:41 +0200 (MET DST) Message-ID: <396A2A55.5007C252@fokus.gmd.de> Date: Mon, 10 Jul 2000 21:56:05 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: Michael Thomas , Jonathan Rosenberg , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Culpepper, Bert" wrote: > As I understand RTP, there is no guaranteed deliver of RTP packets. > Therefor, the need for a reliable protocol. Also, requiring a 3rd party > platform to process the media adds delay when it is in the middle > of a session between two other endpoints. To recall the reliability discussion (back to November): Reliability is obviously desired (consider banking applications). RFC 2833 deals with packet loss by redundancy, which is subject to burst loss and jitter. SIP INFO uses SIP's exponential retransmission, which lacks real-time property. This may have some unpleasant side-effects: Exponential retransmission may fool human senders who will beleive, they did not press a digit button thoroughly and will press the digit again resulting in digit duplication. (Jonathan R.) Receiver can be fooled to beleive the retransmission gap indicates end of DTMF sequence. (Michael R.) Scott P. proposed to handle packet loss at application layer if redundancy is used and fails. (If a banking PC is asked to make a transaction it prompts all data before really doing so.) Jiri -- Jiri Kuthan Phone: +49-30-3463 7271 GMD FOKUS Fax : +49-30-3463 8271 Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de D-10589 Berlin, Germany WWW : http://www.fokus.gmd.de/usr/kuthan -- Curious about Internet Telephony? Check http://www.fokus.gmd.de/glone/projects/ipt today! _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 16:30:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27299 for ; Mon, 10 Jul 2000 16:30:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 262A44438D; Mon, 10 Jul 2000 16:29:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounce.harvard.net (bounce.harvard.net [140.239.141.158]) by lists.bell-labs.com (Postfix) with ESMTP id B69FD44343 for ; Mon, 10 Jul 2000 16:29:51 -0400 (EDT) Received: from lockdown.harvard.net (miva-admin.harvard.net [140.239.141.145]) by bounce.harvard.net (8.10.1/8.10.1) with ESMTP id e6AKToO03751; Mon, 10 Jul 2000 16:29:50 -0400 Received: from flyhalf.PACTOLUS.com (wks194.pactolus.com [140.239.14.194] (may be forged)) by lockdown.harvard.net (8.9.3/8.9.3) with ESMTP id QAA15189; Mon, 10 Jul 2000 16:29:50 -0400 Received: by wks194.pactolus.com with Internet Mail Service (5.5.2650.21) id <3V2B6HZM>; Mon, 10 Jul 2000 16:39:41 -0400 Message-ID: <2CC2CB3C95C3D311ABAC009027DCD77E86DF@wks194.pactolus.com> From: "Girzon, Gary" To: "'Henning Schulzrinne'" , "Culpepper, Bert" Cc: Michael Thomas , Jonathan Rosenberg , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Mon, 10 Jul 2000 16:39:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com An example of where "DTMF over RTP" and "DTMF over SIP INFO" methods can be both used is a pre-paid application. Pre-paid falls into a general category of 3rd party call-control apps in which a controlling party typically does not care about audio between the other 2 parties but wishes to be notified about certain in-band audio events such as DTMF. Initially, the controlling party receives DTMF over RTP. After the transfering a call, there is no need for the controlling party to remain in the RTP or media "loop" and waste connection resources. Again, I don't think anyone is proposing tunneling MGCP or Megaco over SIP, just recycling some of the already defined packages for syntax defining DTMF events. Gary PS: The usual disclaimers about this being a legacy PSTN type application apply... > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Monday, July 10, 2000 3:43 PM > To: Culpepper, Bert > Cc: Michael Thomas; Jonathan Rosenberg; Igor Slepchin; Shankar, > Krishnakumar; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DTMF digit handling > > > "Culpepper, Bert" wrote: > > > > > > > As I understand RTP, there is no guaranteed deliver of RTP packets. > > Therefor, the need for a reliable protocol. Also, > requiring a 3rd party > > platform to process the media adds delay when it is in the middle > > of a session between two other endpoints. > > > > > > We've had this discussion a few times in the last few years, but this > seems to be a recurring misperception. DTMF-over-RTP is roughly as > reliable as any UDP or TCP-based protocol. All three, > SIP-over-UDP, RFC > 2833 and SIP-over-TCP, rely on retransmission (ACK-based or > "FEC"-based), just at different layer. All can fail, > eventually, if too > many packets are lost in a row. (TCP will retranmsmit for a long time, > but it is not clear whether receiving a DTMF digit an hour or even > thirty seconds after the key was pressed is very useful. You probably > need to have an application-layer timeout in any event, as in "sorry, > your number is incomplete, please redial".) In most cases, RTP-based > retransmission is much faster than TCP-based retransmission, in line > with the real-time requirements of outbound PSTN gateways. > > Besides, as discussed here a few times, if you prefer the TCP model of > reliability, you can carry RTP in TCP. > > The delay issue is also bogus, since you can forward the voice packet > even before you do the analysis (unless you need to synchronize tones > and audio at the outbound IP-to-PSTN gateway, but then SIP or anything > else that doesn't have precise timing information isn't going to help > you.) > > > -- > 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 Jul 10 16:36:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27525 for ; Mon, 10 Jul 2000 16:36:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DFFC443C9; Mon, 10 Jul 2000 16:35:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8E6A2443BE for ; Mon, 10 Jul 2000 16:35:51 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA19636; Mon, 10 Jul 2000 16:35:48 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA04131; Mon, 10 Jul 2000 16:35:47 -0400 (EDT) Message-ID: <396A33A3.2C595AE0@cs.columbia.edu> Date: Mon, 10 Jul 2000 16:35:47 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Girzon, Gary" Cc: "Culpepper, Bert" , Michael Thomas , Jonathan Rosenberg , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: <2CC2CB3C95C3D311ABAC009027DCD77E86DF@wks194.pactolus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Girzon, Gary" wrote: > > An example of where "DTMF over RTP" and "DTMF over SIP INFO" methods > can be both used is a pre-paid application. Pre-paid falls into a general > category > of 3rd party call-control apps in which a controlling party typically does > not care > about audio between the other 2 parties but wishes to be notified about > certain > in-band audio events such as DTMF. Initially, the controlling party > receives > DTMF over RTP. After the transfering a call, there is no need for > the controlling party to remain in the RTP or media "loop" and waste > connection resources. That party should then disconnect the DTMF RTP stream, using existing SIP "drop media" mechanisms. (I actually doubt this works in practice, since most such prepaid applications allow the user to "hang up" and redial by holding down the # key for two seconds, compensating for the lack of cookies in payphones.) > > Again, I don't think anyone is proposing tunneling MGCP or Megaco over SIP, > just recycling some of the already defined packages for syntax defining DTMF > events. > The person(s) doing the proposing can speak for themselves :-) -- 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 Jul 10 16:44:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27786 for ; Mon, 10 Jul 2000 16:44:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 629EB443E2; Mon, 10 Jul 2000 16:44:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from empowertel.com (unknown [64.220.200.243]) by lists.bell-labs.com (Postfix) with ESMTP id C54D044336 for ; Mon, 10 Jul 2000 16:44:10 -0400 (EDT) Received: from rajeev ([192.168.111.39]) by empowertel.com (8.9.3+Sun/8.9.3) with SMTP id NAA12441; Mon, 10 Jul 2000 13:41:55 -0700 (PDT) Reply-To: From: "Rajeev Gupta" To: "'Henry Sinnreich'" , "'Dave Walker'" , Subject: RE: [SIP] Announcement of SIP Forum Date: Mon, 10 Jul 2000 13:41:23 -0700 Message-ID: <012001bfeaaf$364dada0$276fa8c0@empowertel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I apologize if I am flogging a dead horse but... The latest discussion in the Softswitch Consortium's SIP working group was precisely along these lines i.e. to take the call flows I-D and implement test cases based on that that can be used to certify conformance of SIP implementations. The implementation would probably be done by an independent 3rd party (such as UNH) which could also host the test lab (presumably, fees would be charged to cover test costs). The real work I see here is the implementation of call flow test cases in a manner that is easy to test against. Since the call flows are open, any vendor could implement them in-house to test conformance. The "certification program" would be for those that want to avail of it to expedite their testing, and would ensure conformance against a common set of test cases, to promote interoperability. Rajeev Gupta empowerTel Networks 475 Sycamore Drive, Milpitas, CA 95035 Phone: +1 408 519 7136 Fax: +1 408 519 7399 mailto:rajeev@empowertel.com http://www.empowertel.com -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henry Sinnreich Sent: Sunday, June 25, 2000 2:23 PM To: Dave Walker; sip@lists.bell-labs.com Subject: RE: [SIP] Announcement of SIP Forum I have serious misgivings about a certification program. The SIP bakeoffs provide excellent and discreet info that helps vendors correct their bugs. Would rather see vendors stating compliance with the published I-D's with call flows. Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dave Walker >Sent: Thursday, June 22, 2000 1:19 PM >To: 'sip@lists.bell-labs.com' >Subject: Re: [SIP] Announcement of SIP Forum > > >In case anyone is not aware of it, I believe that this type >of certification program is currently being considered by the >SIP Working Group in the Softswitch Consortium (which is *not* >looking for post-H.323 work!). > >Dave Walker >SS8 Networks >Ottawa, Canada > > >Henning Schulzrinne wrote: >> >> One of the ideas that was discussed at the Telia >dinner in Stockholm was >> whether there was a need for a basic SIP >certification program. There >> are obvious pluses and minuses for this, but my >concern is that if this >> is a real need, I can think of a few organizations >(looking for >> post-H.323 work...) that I would rather *not* see doing 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 > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/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 Jul 10 16:57:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28106 for ; Mon, 10 Jul 2000 16:57:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F5D544391; Mon, 10 Jul 2000 16:56:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 634C244383 for ; Mon, 10 Jul 2000 16:56:20 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id PAA23951; Mon, 10 Jul 2000 15:54:49 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jul 2000 15:49:13 -0500 Message-ID: From: "Culpepper, Bert" To: Henning Schulzrinne Cc: Michael Thomas , Jonathan Rosenberg , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Mon, 10 Jul 2000 15:49:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I'm reminded (by Colin) that RFC2833 supports re-transmission. This works for me. Additional delay (when in the media path between two endpoints) is a problem for me. I don't have the luxury of building my own RTP/ network interfaces. I suppose I can "turn off" the jitter buffer on the commercially available network interfaces I'm aware of and pass RTP to the other end, resulting in minimal delay. But then I'd have to build my own packet sequencer. This is do-able, I have to look at the packet timestamps and event duration anyway. But if transported in an INFO message, all I have to do is analyze the RTP packets containing the DTMF and stay out of the media path altogether. Delay is a non-issue then. Bert > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Monday, July 10, 2000 3:43 PM > To: Culpepper, Bert > Cc: Michael Thomas; Jonathan Rosenberg; Igor Slepchin; Shankar, > Krishnakumar; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DTMF digit handling > > > "Culpepper, Bert" wrote: > > > > > > > As I understand RTP, there is no guaranteed deliver of RTP packets. > > Therefor, the need for a reliable protocol. Also, requiring a 3rd party > > platform to process the media adds delay when it is in the middle > > of a session between two other endpoints. > > > > > > We've had this discussion a few times in the last few years, but this > seems to be a recurring misperception. DTMF-over-RTP is roughly as > reliable as any UDP or TCP-based protocol. All three, SIP-over-UDP, > RFC > 2833 and SIP-over-TCP, rely on retransmission (ACK-based or > "FEC"-based), just at different layer. All can fail, eventually, if > too > many packets are lost in a row. (TCP will retranmsmit for a long time, > but it is not clear whether receiving a DTMF digit an hour or even > thirty seconds after the key was pressed is very useful. You probably > need to have an application-layer timeout in any event, as in "sorry, > your number is incomplete, please redial".) In most cases, RTP-based > retransmission is much faster than TCP-based retransmission, in line > with the real-time requirements of outbound PSTN gateways. > > Besides, as discussed here a few times, if you prefer the TCP model of > reliability, you can carry RTP in TCP. > > The delay issue is also bogus, since you can forward the voice packet > even before you do the analysis (unless you need to synchronize tones > and audio at the outbound IP-to-PSTN gateway, but then SIP or anything > else that doesn't have precise timing information isn't going to help > you.) > > > -- > 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 Jul 10 17:30:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29181 for ; Mon, 10 Jul 2000 17:30:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AC1D443A4; Mon, 10 Jul 2000 17:30:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id A1CCA44383 for ; Mon, 10 Jul 2000 17:30:16 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id QAA24656; Mon, 10 Jul 2000 16:30:09 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jul 2000 16:24:46 -0500 Message-ID: From: "Culpepper, Bert" To: Henning Schulzrinne , "Girzon, Gary" Cc: Michael Thomas , Jonathan Rosenberg , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Mon, 10 Jul 2000 16:24:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Monday, July 10, 2000 4:36 PM > To: Girzon, Gary > Cc: Culpepper, Bert; Michael Thomas; Jonathan Rosenberg; Igor > Slepchin; > Shankar, Krishnakumar; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DTMF digit handling > > > "Girzon, Gary" wrote: > > > > An example of where "DTMF over RTP" and "DTMF over SIP INFO" methods > > can be both used is a pre-paid application. Pre-paid falls into a general > > category > > of 3rd party call-control apps in which a controlling party typically does > > not care > > about audio between the other 2 parties but wishes to be notified about > > certain > > in-band audio events such as DTMF. Initially, the controlling party > > receives > > DTMF over RTP. After the transfering a call, there is no need for > > the controlling party to remain in the RTP or media "loop" and waste > > connection resources. > > That party should then disconnect the DTMF RTP stream, using existing > SIP "drop media" mechanisms. (I actually doubt this works in practice, > since most such prepaid applications allow the user to "hang up" and > redial by holding down the # key for two seconds, compensating for the > lack of cookies in payphones.) > Exactly, I can't provide all of the features of pre-paid (or post-paid) calling cards on a SIP server without someway to get that 2-second # key after I've re-directed the media. > > > > > Again, I don't think anyone is proposing tunneling MGCP or Megaco over SIP, > > just recycling some of the already defined packages for syntax defining DTMF > > events. > > > The person(s) doing the proposing can speak for themselves :-) > I'm not sure what I've proposed :) but "recycling" is a nice term (since tunneling is so reprehensible). Existing methods (183 Session Progress, G.711) work at session establishment. And it seems RFC2833 encoded DTMF in a mid-session INFO message is best for that point in a session. Well, I hope to find out what is acceptable in the near future. I understand what I proposed in a Draft probably violates SIP's purpose but I would like a way to provide a digit mask and have the digits collected at the gateway and reported in a single result message. And a network that has MGCP/Megaco in places and SIP in other places is likely to be reality. I guess we can't always have what we want though :) > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > Bert _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 20:52:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02609 for ; Mon, 10 Jul 2000 20:52:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 309624436A; Mon, 10 Jul 2000 20:52:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.huawei.com.cn (unknown [202.96.135.132]) by lists.bell-labs.com (Postfix) with ESMTP id 89FD344351 for ; Mon, 10 Jul 2000 20:52:01 -0400 (EDT) Received: from y13638 ([10.105.30.120]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA21048 for ; Tue, 11 Jul 2000 08:53:04 +0800 Message-ID: <002401bfead2$55579c60$781e690a@huawei.com.cn> From: "YinShaoHua" To: Date: Tue, 11 Jul 2000 08:52:48 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01BFEB15.633017C0" 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] test Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0021_01BFEB15.633017C0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 IFRlc3QsIHBsZWFzZSBpbmdvcmUgaXQhDQo= ------=_NextPart_000_0021_01BFEB15.633017C0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDtUZXN0LCBwbGVh c2UgaW5nb3JlIGl0ITwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0021_01BFEB15.633017C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 10 22:45:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05971 for ; Mon, 10 Jul 2000 22:45:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 17DCD443B6; Mon, 10 Jul 2000 22:45:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp.email.msn.com (cpimssmtpu10.smtp.email.msn.com [207.46.181.60]) by lists.bell-labs.com (Postfix) with ESMTP id AF46344339 for ; Mon, 10 Jul 2000 22:44:58 -0400 (EDT) Received: from computer - 63.14.43.104 by email.msn.com with Microsoft SMTPSVC; Mon, 10 Jul 2000 19:44:30 -0700 Message-ID: <000701bfeae2$1de02300$4025fea9@computer> From: "rahnkp" To: , "Rohan Mahy" References: <4.2.0.58.20000706104920.00de0af0@lint.cisco.com> Subject: Re: [SIP] harmonized SUBSCRIBE/NOTIFY behavior Date: Mon, 10 Jul 2000 20:35:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Please do not send this stuff to me. It's all very interesting, but I am not connected to you folks... Thanks ----- Original Message ----- From: Rohan Mahy To: Sent: Thursday, July 06, 2000 1:16 PM Subject: [SIP] harmonized SUBSCRIBE/NOTIFY behavior > Hi, > > I'm looking for some consistent direction on SUBSCRIBE/NOTIFY. Since we > have the SUBSCRIBE/NOTIFY draft, PINT, and IMPP for presence, all doing > stuff differently. > > I can see valid reasons for each of these cases: > > a subscribe to ongoing state, I already know the current state > b subscribe to ongoing state, plus get current state > c refresh subscription, I know the current state > d refresh subscription, plus get current state > e fetch the current state > f unsubscribe > > Hopefully Jonathan Rosenberg, Scott Petrack, and Adam Roach have all talked > about this somewhere. > My interetation of the currently available documents is that they can do this: > > SUB/NFY a, c, f > PINT a, c, e, f > IMPP b, c, e, f > > Perhaps we need a new header/parameter used in a SUBSCRIBE that indicates > whether to send back immediate status? > > Also, the use of an Event header, Call-ID usage, and body handling are not > consistent, but this seems like less of an issue. > > Anyone care to clarify? Will the three documents be harmonized (apologies > for using an ITU term) at some point? > > Relevant sections of the documents are included below. Also, a short > comment on IMPP inline... > > thanks, > -rohan > > > In draft-roach-sip-subscribe-notify-00.txt, the author asks: > > >Should cancelling a subscription be performed with the UNSUBSCRIBE method > >defined in PINT for the sake of consistency, or is the REGISTER model of > >"Expires: 0" preferable? > > There is no mention of the SUBSCRIBE response carrying back any state. In > the companion document, draft-roach-sip-acb-00.txt, a SUBSCRIBE to the > "terminal-free" event does not necessarily need state in the reply, because > presumably, the subscriber already assumed the terminal wan't free, because > they got a busy signal. > > In RFC2848, the authors state: > > >When a SUBSCRIBE request is sent to a PINT Server, it indicates that a > >user wishes to receive information about the status of a service session. > >The request identifies the session of interest by including the original > >session description along with the request, using the SDP > >global-session-id that forms part of the origin-field to identify the > >service session uniquely. > > >Rather than have two different methods of identifying the "session of > >interest" the choice is to use the origin-field of the SDP sub-part > >included both in the original INVITE and in this SUBSCRIBE request. > > > >Note that the request MUST NOT include any sub-parts other than the > >session description, even if these others were present in the original > >INVITE request. A server MUST ignore whatever sub-parts are included > >within a SUBSCRIBE request with the sole exception of the enclosed session > >description. The request MAY contain a "Contact:" header, specifying the > >PINT User Agent Server to which such information should be sent. > > > >In addition, it SHOULD contain an Expires: header, which indicates for how > >long the PINT Requestor wishes to receive notification of the session > >status. We refer to the period of time before the expiration of the > >SUBSCRIBE request as the "subscription period". See section 5.1.4. for > >security considerations, particularly privacy implications. > > > >A value of 0 within the Expires: header indicates a desire to receive one > >single immediate response (i.e. the request expires immediately). It is > >possible for a sequence of monitoring sessions to be opened, exist, and > >complete, all relating to the same service session. > > > >A successful response to the SUBSCRIBE request includes the session > >description, according to the Gateway. Normally this will be identical to > >the last cached response that the Gateway returned to any request > >concerning the same SDP global session id (see [2], section 6, o= field). > >The t= line may be altered to indicate the actual start or stop time, > >however. The Gateway might add an i= line to the session description to > >indicate such information as how many fax pages were sent. The Gateway > >SHOULD include an Expires: header indicating how long it is willing to > >maintain the monitoring session. If this is unacceptable to the PINT > >Requestor, then it can close the session by sending an immediate > >UNSUBSCRIBE message (see 3.5.3.3). > > > >At some point, either the Client's representative User Agent Server or the > >Gateway may decide to terminate the monitoring session. This is achieved > >by sending an UNSUBSCRIBE request to the correspondent server. Such a > >request indicates that the sender intends to close the monitoring session > >immediately, and, on receipt of the final response from the receiving > >server, the session is deemed over. > > > >Note that unlike the SUBSCRIBE request, which is never sent by a PINT > >gateway, an UNSUBSCRIBE request can be sent by a PINT gateway to the User > >Agent Server to indicate that the monitoring session is closed. (This is > >analogous to the fact that a gateway never sends an INVITE, although it > >can send a BYE to indicate that a telephone call has ended.) > > > >If the Gateway initiates closure of the monitoring session by sending an > >UNSUBSCRIBE message, it SHOULD include an "Expires:" header showing for > >how much longer after this monitoring session is closed it is willing to > >store information on the service session. This acts as a minimum time > >within which the Client can send a new SUBSCRIBE message to open another > >monitoring session; after the time indicated in the Expires: header the > >Gateway is free to dispose of any record of the service session, so that > >subsequent SUBSCRIBE requests can be rejected with a "606" response. > > > >If the subscription period specified by the Client has expired, then the > >Gateway may send an immediate UNSUBSCRIBE request to the Client's > >representative User Agent Server. This ensures that the monitoring session > >always completes with a UNSUBSCRIBE/response exchange, and that the > >representative User Agent Server can avoid maintaining state in certain > >circumstances. > > > In draft-rosenberg-impp-presence-00.txt, the authors state: > > >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. > > Jonathan, instead of the first sentence I propose something like this: > > "A SUBSCRIBE request MUST contain a Contact header, unless the SUBSCRIBE > request is used for Fetching currect state only (see section 5.8)." OR > > "An ordinary SUBSCRIBE request MUST contain a Contact header. A SUBSCRIBE > request without a Contact is used for Fetching current state only, and does > not cause notifications." > > >[When replying to a new subscription,] The 200 OK response SHOULD also > >contain a copy of the current presence state of the presentity. > > >A subscriber may unsubscribe by sending a SUBSCRIBE request with an > >Expires header of 0. The Contact header indicates the particular address > >that is being unsubscribed. This MAY be a *, indicating that all Contacts > >for that particular subscription (as identified by the Call-ID, To, and > >From) are to be removed. If all Contacts are removed, the PA deletes the > >subscription. > > >Fetching is similar to a subscribing, in that it returns the current > >presence state. However, no notifications are sent for future changes in > >the presence state. Rather than inventing a new method for this, it is > >readily accomplished with a SUBSCRIBE along with an Expires: 0 header and > >no Contact header. The absence of any Contact header is what distinguishes > >it from the similar operation of unsubscribing. The advantage of using > >SUBSCRIBE is that the server can simply process the request independently > >of whether its a fetch or longer lived subscription; the authorization and > >processing steps are identical. The only difference is whether an actual > >subscription is instantiated for the user or not. > > > >This parallels how fetching of registrations is done in SIP. Note that > >fetching has no effect on existing subscriptions. > > > 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 Jul 10 23:13:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06409 for ; Mon, 10 Jul 2000 23:13:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D9B3F44422; Mon, 10 Jul 2000 23:12:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp.email.msn.com (cpimssmtpu09.email.msn.com [207.46.181.31]) by lists.bell-labs.com (Postfix) with ESMTP id 41FDA44354 for ; Mon, 10 Jul 2000 23:12:51 -0400 (EDT) Received: from computer - 63.14.43.104 by email.msn.com with Microsoft SMTPSVC; Mon, 10 Jul 2000 20:06:48 -0700 Message-ID: <000a01bfeae5$3b9b3120$4025fea9@computer> From: "rahnkp" To: "YinShaoHua" , References: <002401bfead2$55579c60$781e690a@huawei.com.cn> Subject: Re: [SIP] test Date: Mon, 10 Jul 2000 21:08:03 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BFEAB2.EFEC9200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BFEAB2.EFEC9200 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Please remove me from your lists. I have received over 300 messages this = past week, and I don't think you want me to have access to this info. Thanks. Rahn Porter ----- Original Message -----=20 From: YinShaoHua=20 To: sip@lists.bell-labs.com=20 Sent: Monday, July 10, 2000 6:52 PM Subject: [SIP] test Test, please ingore it! ------=_NextPart_000_0007_01BFEAB2.EFEC9200 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Please remove me from your lists. I = have received=20 over 300 messages this past week, and I don't think you want me to have = access=20 to this info.
 
Thanks.
Rahn  Porter
----- Original Message -----
From:=20 YinShaoHua=20
To: sip@lists.bell-labs.com
Sent: Monday, July 10, 2000 = 6:52 PM
Subject: [SIP] test

 Test, please ingore=20 it!
------=_NextPart_000_0007_01BFEAB2.EFEC9200-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 01:12:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09124 for ; Tue, 11 Jul 2000 01:12:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 21149443CD; Tue, 11 Jul 2000 01:11:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9709644336 for ; Tue, 11 Jul 2000 01:11:54 -0400 (EDT) Received: from dynamicsoft.com (1Cust214.tnt4.freehold.nj.da.uu.net [63.36.112.214]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA07532; Tue, 11 Jul 2000 01:13:15 -0400 (EDT) Message-ID: <396AAD44.3CB04D77@dynamicsoft.com> Date: Tue, 11 Jul 2000 01:14:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: Michael Thomas , "Fairlie-Cuninghame, Robert" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Culpepper, Bert" wrote: > > > RFC2833 solves distortion issues with low bit-rate codecs. And I, > myself don't see the use of DTMF with IP Phones or PCs. Where > I see DTMF in a SIP network is when SIP (and RTP) carries PSTN > traffic. We can either support the existing services (and new services > possible with IP networks) offered by telecommunications service > providers or tell them SIP in part of their network won't work if they > are not willing to accept the loss of voice quality and some existing > service features. I really, REALLY hate "threats" like this, which are occassionally made on the list (in fact, often around DTMF). THings of the form "but if you don't do X, service provids will use some other protocol, so you better extend SIP to do X for me". Lets debate the technical issues and stay away from these kinds of tactics. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 01:23:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10825 for ; Tue, 11 Jul 2000 01:23:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DCAAE443D1; Tue, 11 Jul 2000 01:23:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 53BA64437E for ; Tue, 11 Jul 2000 01:23:37 -0400 (EDT) Received: from dynamicsoft.com (1Cust214.tnt4.freehold.nj.da.uu.net [63.36.112.214]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA07541; Tue, 11 Jul 2000 01:24:44 -0400 (EDT) Message-ID: <396AAFF5.F74ABC44@dynamicsoft.com> Date: Tue, 11 Jul 2000 01:26:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Girzon, Gary" Cc: "'Henning Schulzrinne'" , "Culpepper, Bert" , Michael Thomas , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: <2CC2CB3C95C3D311ABAC009027DCD77E86DF@wks194.pactolus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Girzon, Gary" wrote: > > An example of where "DTMF over RTP" and "DTMF over SIP INFO" methods > can be both used is a pre-paid application. Pre-paid falls into a general > category > of 3rd party call-control apps in which a controlling party typically does > not care > about audio between the other 2 parties but wishes to be notified about > certain > in-band audio events such as DTMF. Initially, the controlling party > receives > DTMF over RTP. After the transfering a call, there is no need for > the controlling party to remain in the RTP or media "loop" and waste > connection resources. Part of the confusion are the different pictures people have in their heads about the architecture for providing these services. Pre-paid is a classic example of an app where the media stream must be terminated by a SIP UA anyway, for generating prompts and the like. Let me draw a picture of how I view this service being architected: +-----------+ | media | | server | | | x control +-----------+ xx x . x . +---------+ . | app | . | server | \ RTP. / | | \ . / +---------+ \ SIP . / \ . / SIP \ . / +-------+ +-------+ | | | | | | | | | UAS | | UAC |...................... | | | | | | +-------+ RTP +-------+ The UAC makes a call (a gateway, typically), and its SIP INVITE arrives at an app server handling the pre-paid calling application. Using 3pcc, this app server sends a 183, and includes in it SDP corresponding to the address of some media server. The media server terminates the RTP from the UAC; its the one thats going to play the prompts and extract DTMF. Now, once the credit card information has been collected, you'd like that information to be sent back to the app server via some control protocol, X, to be determined. Once thats done, the app server sends the INVITE the the UAS, which sends 200 OK, and the UAC now sends RTP directly to the UAS. In this model, the app server never sees media. Media is always directly sent between the entities communicating. There are no extra delays. We do not need DTMF in SIP, since the media server is terminating and originating RTP. What we do need is some sort of control protocol between the app server and the media server. This would be used to control the IVR prompts, collect the credit card, and get it back. Many people like megaco/mgcp here. I, frankly, much prefer VoiceXML as it is oodles easier to program and plays very nicely with SIP. Anyway, whatever it is, that control protocol reports the DTMF as needed. Note that this interface is NOT SIP. If someone has a different architecture in mind for this service, speak up. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 11:18:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03902 for ; Tue, 11 Jul 2000 11:18:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 300C744354; Tue, 11 Jul 2000 11:18:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounce.harvard.net (bounce.harvard.net [140.239.141.158]) by lists.bell-labs.com (Postfix) with ESMTP id E6EC144336 for ; Tue, 11 Jul 2000 11:18:24 -0400 (EDT) Received: from lockdown.harvard.net (miva-admin.harvard.net [140.239.141.145]) by bounce.harvard.net (8.10.1/8.10.1) with ESMTP id e6BFINO24332; Tue, 11 Jul 2000 11:18:23 -0400 Received: from flyhalf.PACTOLUS.com (wks194.pactolus.com [140.239.14.194] (may be forged)) by lockdown.harvard.net (8.9.3/8.9.3) with ESMTP id LAA26118; Tue, 11 Jul 2000 11:18:20 -0400 Received: by wks194.pactolus.com with Internet Mail Service (5.5.2650.21) id <3V2B6H0V>; Tue, 11 Jul 2000 11:28:13 -0400 Message-ID: <2CC2CB3C95C3D311ABAC009027DCD77E0AB9C0@wks194.pactolus.com> From: "Girzon, Gary" To: "'Jonathan Rosenberg'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Tue, 11 Jul 2000 11:28:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I don't have any issues with the architecture below or the call flow. Yes, the Media Server initially collects DTMF information directly via RTP but once the RTP connection between UAS and UAC is set up, there is no need for the UAC - Media Server RTP connection. Maintaining the RTP connection just for DTMF digit collection (required to collect the long # and any others) is really a waste of resources on the Media Server, not to mention extra bandwidth. Typically, there is 1:7 mapping of Media Server to Caller resources - i.e., the Media Server plays a prompt, collects a few digits and then dis-engages. That Media Server port can be re-used for other Media Applications. Once the Caller hits #, the Media Server gets reconnected, plays prompts and collects digits again. So the real question is how to collect the long # and any any other DTMF while UAC and UAS are connected. This is where I think SIP INFO method provides a good solution. Does anyone have another method of sending DTMF information from UAC not requiring an RTP connection to the Media Server? As for the protocol between the App Server and Media Server, that's a whole other discussion... Gary Girzon Principal Software Engineer Pactolus Communication Software, Inc. 55 New York Avenue Framingham, MA 01701 Office: 508-620-5519 x 208 ggirzon@pactolus.com www.pactolus.com > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 11, 2000 1:26 AM > To: Girzon, Gary > Cc: 'Henning Schulzrinne'; Culpepper, Bert; Michael Thomas; Igor > Slepchin; Shankar, Krishnakumar; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DTMF digit handling > > > > > "Girzon, Gary" wrote: > > > > An example of where "DTMF over RTP" and "DTMF over SIP INFO" methods > > can be both used is a pre-paid application. Pre-paid falls > into a general > > category > > of 3rd party call-control apps in which a controlling party > typically does > > not care > > about audio between the other 2 parties but wishes to be > notified about > > certain > > in-band audio events such as DTMF. Initially, the controlling party > > receives > > DTMF over RTP. After the transfering a call, there is no need for > > the controlling party to remain in the RTP or media "loop" and waste > > connection resources. > > Part of the confusion are the different pictures people have in their > heads about the architecture for providing these services. > Pre-paid is a > classic example of an app where the media stream must be > terminated by a > SIP UA anyway, for generating prompts and the like. Let me draw a > picture of how I view this service being architected: > > > +-----------+ > | media | > | server | > | | x control > +-----------+ xx > x > . x > . +---------+ > . | app | > . | server | \ > RTP. / | | \ > . / +---------+ \ SIP > . / \ > . / SIP \ > . / +-------+ > +-------+ | | > | | | | > | | | UAS | > | UAC |...................... | | > | | | | > +-------+ RTP +-------+ > > The UAC makes a call (a gateway, typically), and its SIP > INVITE arrives > at an app server handling the pre-paid calling application. > Using 3pcc, > this app server sends a 183, and includes in it SDP > corresponding to the > address of some media server. The media server terminates the RTP from > the UAC; its the one thats going to play the prompts and extract DTMF. > Now, once the credit card information has been collected, you'd like > that information to be sent back to the app server via some control > protocol, X, to be determined. Once thats done, the app > server sends the > INVITE the the UAS, which sends 200 OK, and the UAC now sends RTP > directly to the UAS. > > In this model, the app server never sees media. Media is > always directly > sent between the entities communicating. There are no extra delays. We > do not need DTMF in SIP, since the media server is terminating and > originating RTP. > > What we do need is some sort of control protocol between the > app server > and the media server. This would be used to control the IVR prompts, > collect the credit card, and get it back. Many people like megaco/mgcp > here. I, frankly, much prefer VoiceXML as it is oodles easier > to program > and plays very nicely with SIP. Anyway, whatever it is, that control > protocol reports the DTMF as needed. Note that this interface is NOT > SIP. > > If someone has a different architecture in mind for this > service, speak > up. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 11: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 ESMTP id LAA04358 for ; Tue, 11 Jul 2000 11:30:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 66DD1443A3; Tue, 11 Jul 2000 11:29:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id ED15B44393 for ; Tue, 11 Jul 2000 11:29:40 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA16564; Tue, 11 Jul 2000 08:29:52 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11647; Tue, 11 Jul 2000 08:29:43 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14699.15719.482486.757726@thomasm-u1.cisco.com> Date: Tue, 11 Jul 2000 08:29:43 -0700 (PDT) To: "Girzon, Gary" Cc: "'Jonathan Rosenberg'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling In-Reply-To: <2CC2CB3C95C3D311ABAC009027DCD77E0AB9C0@wks194.pactolus.com> References: <2CC2CB3C95C3D311ABAC009027DCD77E0AB9C0@wks194.pactolus.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Girzon, Gary writes: > I don't have any issues with the architecture below or > the call flow. Yes, the Media Server initially collects DTMF information > directly via RTP but once the RTP connection between UAS > and UAC is set up, there is no need for the UAC - Media Server > RTP connection. Maintaining the RTP connection just for DTMF > digit collection (required to collect the long # and any > others) is really a waste of resources on the Media Server, > not to mention extra bandwidth. Typically, there is 1:7 mapping > of Media Server to Caller resources - i.e., the Media Server > plays a prompt, collects a few digits and then dis-engages. > That Media Server port can be re-used for other Media > Applications. Once the Caller hits #, the Media Server gets > reconnected, plays prompts and collects digits again. Assuming the UAC is sending named signaling events, it seems to me that it's six of one, half dozen of the other of whether the media server monitors the call for more digits using RTP or SIP INFO methods. Given that the media server needs to deal with things like duration (ie long #), NSE's seem like a lot better approach, and to my mind fits the SIP architecture a whole lot better: SIP's good at initiating media streams; it's pretty lousy at being a device control protocol. Essentially it's just a DTMF multiparty conference. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 11:49:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05367 for ; Tue, 11 Jul 2000 11:49:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 961C3443ED; Tue, 11 Jul 2000 11:34:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id 36F574435F for ; Mon, 10 Jul 2000 21:36:46 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FXI00E01F55Q1@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 11 Jul 2000 01:36:41 +0000 (GMT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FXI00C3NF55L3@firewall.mcit.com>; Tue, 11 Jul 2000 01:36:41 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) id <0FXI00E01F55PP@pmismtp02.wcomnet.com>; Tue, 11 Jul 2000 01:36:41 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0FXI00E01F51P7@pmismtp02.wcomnet.com>; Tue, 11 Jul 2000 01:36:40 +0000 (GMT) Received: from C25776A ([166.46.19.173]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0FXI00DL9F4RJL@pmismtp02.wcomnet.com>; Tue, 11 Jul 2000 01:36:33 +0000 (GMT) Date: Mon, 10 Jul 2000 20:36:28 -0500 From: Henry Sinnreich Subject: RE: [SIP] DTMF digit handling In-reply-to: To: "Culpepper, Bert" , Henning Schulzrinne , "Girzon, Gary" Cc: Michael Thomas , Jonathan Rosenberg , Igor Slepchin , "Shankar, Krishnakumar" , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Please help me understand >And a network >that has MGCP/Megaco in places and SIP in other places why cannot the IP telephony gateway behave like a SIP endpoint? Thanks, Henry >-----Original Message----- >From: sip-admin@lists.bell-labs.com >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of >Culpepper, Bert >Sent: Monday, July 10, 2000 4:25 PM >To: Henning Schulzrinne; Girzon, Gary >Cc: Michael Thomas; Jonathan Rosenberg; Igor Slepchin; Shankar, >Krishnakumar; 'sip@lists.bell-labs.com' >Subject: RE: [SIP] DTMF digit handling > > > >> -----Original Message----- >> From: Henning Schulzrinne >[mailto:schulzrinne@cs.columbia.edu] >> Sent: Monday, July 10, 2000 4:36 PM >> To: Girzon, Gary >> Cc: Culpepper, Bert; Michael Thomas; Jonathan >Rosenberg; Igor >> Slepchin; >> Shankar, Krishnakumar; 'sip@lists.bell-labs.com' >> Subject: Re: [SIP] DTMF digit handling >> >> >> "Girzon, Gary" wrote: >> > >> > An example of where "DTMF over RTP" and "DTMF over >SIP INFO" methods >> > can be both used is a pre-paid application. >Pre-paid falls into a >general >> > category >> > of 3rd party call-control apps in which a >controlling party typically >does >> > not care >> > about audio between the other 2 parties but wishes >to be notified about >> > certain >> > in-band audio events such as DTMF. Initially, the >controlling party >> > receives >> > DTMF over RTP. After the transfering a call, there >is no need for >> > the controlling party to remain in the RTP or >media "loop" and waste >> > connection resources. >> >> That party should then disconnect the DTMF RTP >stream, using existing >> SIP "drop media" mechanisms. (I actually doubt this >works in practice, >> since most such prepaid applications allow the user >to "hang up" and >> redial by holding down the # key for two seconds, >compensating for the >> lack of cookies in payphones.) >> > >Exactly, I can't provide all of the features of >pre-paid (or post-paid) >calling >cards on a SIP server without someway to get that >2-second # key after >I've re-directed the media. > >> >> > >> > Again, I don't think anyone is proposing tunneling >MGCP or Megaco over >SIP, >> > just recycling some of the already defined >packages for syntax defining >DTMF >> > events. >> > >> The person(s) doing the proposing can speak for >themselves :-) >> > >I'm not sure what I've proposed :) but "recycling" is >a nice term (since >tunneling >is so reprehensible). > >Existing methods (183 Session Progress, G.711) work at session >establishment. And it seems RFC2833 encoded DTMF in a >mid-session >INFO message is best for that point in a session. >Well, I hope to find >out what is acceptable in the near future. > >I understand what I proposed in a Draft probably >violates SIP's purpose but >I >would like a way to provide a digit mask and have the >digits collected >at the gateway and reported in a single result >message. And a network >that has MGCP/Megaco in places and SIP in other places >is likely to be >reality. I guess we can't always have what we want though :) > >> -- >> Henning Schulzrinne http://www.cs.columbia.edu/~hgs >> > >Bert > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 11:55:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05645 for ; Tue, 11 Jul 2000 11:55:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3207144438; Tue, 11 Jul 2000 11:36:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id C52024442C for ; Tue, 11 Jul 2000 11:36:27 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id KAA31297; Tue, 11 Jul 2000 10:35:41 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jul 2000 10:30:18 -0500 Message-ID: From: "Culpepper, Bert" To: Jonathan Rosenberg , "Girzon, Gary" Cc: "'Henning Schulzrinne'" , Michael Thomas , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Tue, 11 Jul 2000 10:30:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The architecture shown matches my view of how a service like pre-paid calling card would be deployed in a SIP network. The call setup scenario also matches my view of the signaling. What is not described, for a service like pre-paid, is how the calling party notifies the app server that it wishes to end the current call and originate a second call without disconnecting completely from the app server and making a new call and going through the credit card validation a second time. I know we're not in the PSTN anymore but this is typically done by pressing and holding the # key for two seconds. What appears to be an acceptable solution to mimic this behavior in a SIP network is to "subscribe" to the DTMF stream (RFC 2833) of the UAC. The RE-INVITE to the UAC will include two media descriptions in the SDP. One for the DTMF to be sent to the media server and the second for the audio to be sent to the UAS. Mid-call event notification in SIP would allow the release of the media server's resource during the conversation portion of the call. One of the DTMF/event reporting proposals (or an equivalent) would allow this. Bert Culpepper Staff Engineer, Systems Design InterVoice-Brite, Inc. http://www.intervoice-brite.com > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 11, 2000 1:26 AM > To: Girzon, Gary > Cc: 'Henning Schulzrinne'; Culpepper, Bert; Michael Thomas; Igor > Slepchin; Shankar, Krishnakumar; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DTMF digit handling > > > > > "Girzon, Gary" wrote: > > > > An example of where "DTMF over RTP" and "DTMF over SIP INFO" methods > > can be both used is a pre-paid application. Pre-paid falls into a> general > > category > > of 3rd party call-control apps in which a controlling party typically does > > not care > > about audio between the other 2 parties but wishes to be notified about > > certain > > in-band audio events such as DTMF. Initially, the controlling party > > receives > > DTMF over RTP. After the transfering a call, there is no need for > > the controlling party to remain in the RTP or media "loop" and waste > > connection resources. > > Part of the confusion are the different pictures people have in their > heads about the architecture for providing these services. Pre-paid is a > classic example of an app where the media stream must be terminated by a > SIP UA anyway, for generating prompts and the like. Let me draw a > picture of how I view this service being architected: > > > +-----------+ > | media | > | server | > | | x control > +-----------+ xx > x > . x > . +---------+ > . | app | > . | server | \ > RTP. / | | \ > . / +---------+ \ SIP > . / \ > . / SIP \ > . / +-------+ > +-------+ | | > | | | | > | | | UAS | > | UAC |...................... | | > | | | | > +-------+ RTP +-------+ > > The UAC makes a call (a gateway, typically), and its SIP INVITE arrives > at an app server handling the pre-paid calling application. Using 3pcc, > this app server sends a 183, and includes in it SDP corresponding to the > address of some media server. The media server terminates the RTP from > the UAC; its the one thats going to play the prompts and extract DTMF. > Now, once the credit card information has been collected, you'd like > that information to be sent back to the app server via some control > protocol, X, to be determined. Once thats done, the app server sends the > INVITE the the UAS, which sends 200 OK, and the UAC now sends RTP > directly to the UAS. > > In this model, the app server never sees media. Media is always directly > sent between the entities communicating. There are no extra delays. We > do not need DTMF in SIP, since the media server is terminating and > originating RTP. > > What we do need is some sort of control protocol between the app server > and the media server. This would be used to control the IVR prompts, > collect the credit card, and get it back. Many people like megaco/mgcp > here. I, frankly, much prefer VoiceXML as it is oodles easier to program > and plays very nicely with SIP. Anyway, whatever it is, that control > protocol reports the DTMF as needed. Note that this interface is NOT > SIP. > > If someone has a different architecture in mind for this service, speak > up. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 12:00:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05896 for ; Tue, 11 Jul 2000 12:00:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9220744444; Tue, 11 Jul 2000 11:36:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id B52614440D for ; Tue, 11 Jul 2000 11:36:27 -0400 (EDT) Received: (qmail 15419 invoked by uid 1002); 11 Jul 2000 15:34:46 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 11 Jul 2000 18:34:45 +0300 (IDT) To: SIP X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14699.15965.59567.455952@jodie.lucid> Subject: [SIP] 415 Unsupported Media Type Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit If I get a new SDP body in the ACK, and I don't like the media type, how can I reply that the media type is unacceptable to me? -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 12: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 ESMTP id MAA07671 for ; Tue, 11 Jul 2000 12:29:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EBBB944369; Tue, 11 Jul 2000 12:29:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lists.bell-labs.com (Postfix) with SMTP id CE08944344 for ; Tue, 11 Jul 2000 12:29:13 -0400 (EDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Jul 2000 09:28:04 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id <3NA42YF7>; Tue, 11 Jul 2000 09:28:03 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01FF5836@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: Jonathan Rosenberg Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Tue, 11 Jul 2000 09:27:56 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > > +-----------+ > > | media | > > | server | > > | | x control > > +-----------+ xx > > x > > . x > > . +---------+ > > . | app | > > . | server | \ > > RTP. / | | \ > > . / +---------+ \ SIP > > . / \ > > . / SIP \ > > . / +-------+ > > +-------+ | | > > | | | | > > | | | UAS | > > | UAC |...................... | | > > | | | | > > +-------+ RTP +-------+ I would add one point. We are in year 2000, not 1980. Engineering for DTMF is fine, but the next release of the "media server" in the above picture is likely to use voice recognition, not DTMF. There have always be two camps when it comes to carrying DTMF, in-band as in the RTP solution detailed above, and out of band through the signalling channel, as proposed many times. The two camps have been resorting to all kinds of comparison, essentially balancing transmission overhead, which is lower in the out-of-band scenario, and architecture simplicity, as in the above diagram. But if you were architecting the system for voice recognition, then there would be no debate whatsoever. To enable voice recognition, you will definitely need an in band solution! The advantage of the above diagram is thus obvious: designing the call flows for in-band carrying of DTMF enables us to use the same flows for DTMF and voice recognition. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 12:32:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07934 for ; Tue, 11 Jul 2000 12:32:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 674CC4438A; Tue, 11 Jul 2000 12:30:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 0B14E4434C for ; Tue, 11 Jul 2000 12:05:21 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TL37W>; Tue, 11 Jul 2000 09:05:17 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE67A900@sd_exchange.nuera.com> From: "Bratakos, Maroula" To: "'Culpepper, Bert'" , Jonathan Rosenberg , "Girzon, Gary" Cc: "'Henning Schulzrinne'" , Michael Thomas , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling Date: Tue, 11 Jul 2000 09:05:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The UAC would actually have to support forking the DTMF stream to both the media server and the UAS because the UAS may want to receive DTMF also. For example, a user accessing a UAC may use their calling card to place a call to their local bank (accessed through the UAS) which requires the user at the UAC to enter their account number. -----Original Message----- From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] Sent: Tuesday, July 11, 2000 8:30 AM To: Jonathan Rosenberg; Girzon, Gary Cc: 'Henning Schulzrinne'; Michael Thomas; Igor Slepchin; Shankar, Krishnakumar; 'sip@lists.bell-labs.com' Subject: RE: [SIP] DTMF digit handling The architecture shown matches my view of how a service like pre-paid calling card would be deployed in a SIP network. The call setup scenario also matches my view of the signaling. What is not described, for a service like pre-paid, is how the calling party notifies the app server that it wishes to end the current call and originate a second call without disconnecting completely from the app server and making a new call and going through the credit card validation a second time. I know we're not in the PSTN anymore but this is typically done by pressing and holding the # key for two seconds. What appears to be an acceptable solution to mimic this behavior in a SIP network is to "subscribe" to the DTMF stream (RFC 2833) of the UAC. The RE-INVITE to the UAC will include two media descriptions in the SDP. One for the DTMF to be sent to the media server and the second for the audio to be sent to the UAS. Mid-call event notification in SIP would allow the release of the media server's resource during the conversation portion of the call. One of the DTMF/event reporting proposals (or an equivalent) would allow this. Bert Culpepper Staff Engineer, Systems Design InterVoice-Brite, Inc. http://www.intervoice-brite.com > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 11, 2000 1:26 AM > To: Girzon, Gary > Cc: 'Henning Schulzrinne'; Culpepper, Bert; Michael Thomas; Igor > Slepchin; Shankar, Krishnakumar; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] DTMF digit handling > > > > > "Girzon, Gary" wrote: > > > > An example of where "DTMF over RTP" and "DTMF over SIP INFO" methods > > can be both used is a pre-paid application. Pre-paid falls into a> general > > category > > of 3rd party call-control apps in which a controlling party typically does > > not care > > about audio between the other 2 parties but wishes to be notified about > > certain > > in-band audio events such as DTMF. Initially, the controlling party > > receives > > DTMF over RTP. After the transfering a call, there is no need for > > the controlling party to remain in the RTP or media "loop" and waste > > connection resources. > > Part of the confusion are the different pictures people have in their > heads about the architecture for providing these services. Pre-paid is a > classic example of an app where the media stream must be terminated by a > SIP UA anyway, for generating prompts and the like. Let me draw a > picture of how I view this service being architected: > > > +-----------+ > | media | > | server | > | | x control > +-----------+ xx > x > . x > . +---------+ > . | app | > . | server | \ > RTP. / | | \ > . / +---------+ \ SIP > . / \ > . / SIP \ > . / +-------+ > +-------+ | | > | | | | > | | | UAS | > | UAC |...................... | | > | | | | > +-------+ RTP +-------+ > > The UAC makes a call (a gateway, typically), and its SIP INVITE arrives > at an app server handling the pre-paid calling application. Using 3pcc, > this app server sends a 183, and includes in it SDP corresponding to the > address of some media server. The media server terminates the RTP from > the UAC; its the one thats going to play the prompts and extract DTMF. > Now, once the credit card information has been collected, you'd like > that information to be sent back to the app server via some control > protocol, X, to be determined. Once thats done, the app server sends the > INVITE the the UAS, which sends 200 OK, and the UAC now sends RTP > directly to the UAS. > > In this model, the app server never sees media. Media is always directly > sent between the entities communicating. There are no extra delays. We > do not need DTMF in SIP, since the media server is terminating and > originating RTP. > > What we do need is some sort of control protocol between the app server > and the media server. This would be used to control the IVR prompts, > collect the credit card, and get it back. Many people like megaco/mgcp > here. I, frankly, much prefer VoiceXML as it is oodles easier to program > and plays very nicely with SIP. Anyway, whatever it is, that control > protocol reports the DTMF as needed. Note that this interface is NOT > SIP. > > If someone has a different architecture in mind for this service, speak > up. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 12:38:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08285 for ; Tue, 11 Jul 2000 12:38:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 833CA443E8; Tue, 11 Jul 2000 12:36:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 952BA44384 for ; Tue, 11 Jul 2000 12:36:43 -0400 (EDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id LAA20946 for ; Tue, 11 Jul 2000 11:36:41 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id LAA01254 for ; Tue, 11 Jul 2000 11:36:41 -0500 (CDT) Received: from b04a19.exu.ericsson.se (b04a19 [138.85.60.119]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA28749 for ; Tue, 11 Jul 2000 11:36:40 -0500 (CDT) Received: from exu.ericsson.se (localhost [127.0.0.1]) by b04a19.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA13189 for ; Tue, 11 Jul 2000 11:36:40 -0500 (CDT) Message-ID: <396B4D17.91603216@exu.ericsson.se> Date: Tue, 11 Jul 2000 11:36:39 -0500 From: Michelle Kitchings Reply-To: Michelle.Kitchings@ericsson.com Organization: Ericsson, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com References: <20000711160004.EB43D4446D@lists.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: SIP digest, Vol 1 #180 - 7 msgs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ok, I'll take a shot at this... In Jonathon's architecture, once the RTP is established between the UAC & UAS, yes, the UAC can break the connection to the media server. Later, when the UAC gets an indication from the user to terminate the current call (UAC-UAS), it will send a BYE to the UAS. At that point, the UAC can re-establish a connection to the media server to monitor for the long '#' and start over with prompt/collect. If no '#' is received after X amount of seconds, the UAC-Media connection is terminated and the pre-paid call is over. There is no reason I can see why the '#' digit has to be collected while the UAC-UAS connection is still ongoing. Cheers, Michelle Kitchings > > Subject: RE: [SIP] DTMF digit handling > Date: Tue, 11 Jul 2000 08:29:43 -0700 (PDT) > From: Michael Thomas > To: "Girzon, Gary" > CC: "'Jonathan Rosenberg'" , > "'sip@lists.bell-labs.com'" > References: <2CC2CB3C95C3D311ABAC009027DCD77E0AB9C0@wks194.pactolus.com> > > > Assuming the UAC is sending named signaling events, > it seems to me that it's six of one, half dozen of > the other of whether the media server monitors the > call for more digits using RTP or SIP INFO methods. > Given that the media server needs to deal with things > like duration (ie long #), NSE's seem like a lot better > approach, and to my mind fits the SIP architecture a > whole lot better: SIP's good at initiating media > streams; it's pretty lousy at being a device control > protocol. Essentially it's just a DTMF multiparty > conference. > > Mike > > Subject: RE: [SIP] DTMF digit handling > Date: Tue, 11 Jul 2000 11:28:12 -0400 > From: "Girzon, Gary" > To: "'Jonathan Rosenberg'" > CC: "'sip@lists.bell-labs.com'" > > I don't have any issues with the architecture below or > the call flow. Yes, the Media Server initially collects DTMF information > directly via RTP but once the RTP connection between UAS > and UAC is set up, there is no need for the UAC - Media Server > RTP connection. Maintaining the RTP connection just for DTMF > digit collection (required to collect the long # and any > others) is really a waste of resources on the Media Server, > not to mention extra bandwidth. Typically, there is 1:7 mapping > of Media Server to Caller resources - i.e., the Media Server > plays a prompt, collects a few digits and then dis-engages. > That Media Server port can be re-used for other Media > Applications. Once the Caller hits #, the Media Server gets > reconnected, plays prompts and collects digits again. > > So the real question is how to collect the long # and any > any other DTMF while UAC and UAS are connected. This is > where I think SIP INFO method provides a good solution. > Does anyone have another method of sending DTMF information > from UAC not requiring an RTP connection to the Media Server? > > As for the protocol between the App Server and Media Server, > that's a whole other discussion... > > Gary Girzon ... > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, July 11, 2000 1:26 AM > > To: Girzon, Gary > > Cc: 'Henning Schulzrinne'; Culpepper, Bert; Michael Thomas; Igor > > Slepchin; Shankar, Krishnakumar; 'sip@lists.bell-labs.com' > > Subject: Re: [SIP] DTMF digit handling > > > > Part of the confusion are the different pictures people have in their > > heads about the architecture for providing these services. > > Pre-paid is a > > classic example of an app where the media stream must be > > terminated by a > > SIP UA anyway, for generating prompts and the like. Let me draw a > > picture of how I view this service being architected: > > > > > > +-----------+ > > | media | > > | server | > > | | x control > > +-----------+ xx > > x > > . x > > . +---------+ > > . | app | > > . | server | \ > > RTP. / | | \ > > . / +---------+ \ SIP > > . / \ > > . / SIP \ > > . / +-------+ > > +-------+ | | > > | | | | > > | | | UAS | > > | UAC |...................... | | > > | | | | > > +-------+ RTP +-------+ > > > > The UAC makes a call (a gateway, typically), and its SIP > > INVITE arrives > > at an app server handling the pre-paid calling application. > > Using 3pcc, > > this app server sends a 183, and includes in it SDP > > corresponding to the > > address of some media server. The media server terminates the RTP from > > the UAC; its the one thats going to play the prompts and extract DTMF. > > Now, once the credit card information has been collected, you'd like > > that information to be sent back to the app server via some control > > protocol, X, to be determined. Once thats done, the app > > server sends the > > INVITE the the UAS, which sends 200 OK, and the UAC now sends RTP > > directly to the UAS. > > > > In this model, the app server never sees media. Media is > > always directly > > sent between the entities communicating. There are no extra delays. We > > do not need DTMF in SIP, since the media server is terminating and > > originating RTP. > > > > What we do need is some sort of control protocol between the > > app server > > and the media server. This would be used to control the IVR prompts, > > collect the credit card, and get it back. Many people like megaco/mgcp > > here. I, frankly, much prefer VoiceXML as it is oodles easier > > to program > > and plays very nicely with SIP. Anyway, whatever it is, that control > > protocol reports the DTMF as needed. Note that this interface is NOT > > SIP. > > > > If someone has a different architecture in mind for this > > service, speak > > up. > > > > -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 Tue Jul 11 12:41:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08498 for ; Tue, 11 Jul 2000 12:41:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EAE18443FD; Tue, 11 Jul 2000 12:37:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id CB0C3443F5 for ; Tue, 11 Jul 2000 12:37:44 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA12415; Tue, 11 Jul 2000 09:37:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA11672; Tue, 11 Jul 2000 09:37:45 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14699.19801.264209.983700@thomasm-u1.cisco.com> Date: Tue, 11 Jul 2000 09:37:45 -0700 (PDT) To: Christian Huitema Cc: Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] DTMF digit handling In-Reply-To: <2E3FA0558747934A8F753CC533A3F6DF01FF5836@red-msg-24.redmond.corp.microsoft.com> References: <2E3FA0558747934A8F753CC533A3F6DF01FF5836@red-msg-24.redmond.corp.microsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Christian Huitema writes: > I would add one point. We are in year 2000, not 1980. Engineering for DTMF > is fine, but the next release of the "media server" in the above picture is > likely to use voice recognition, not DTMF. There have always be two camps > when it comes to carrying DTMF, in-band as in the RTP solution detailed > above, and out of band through the signalling channel, as proposed many > times. The two camps have been resorting to all kinds of comparison, > essentially balancing transmission overhead, which is lower in the > out-of-band scenario, and architecture simplicity, as in the above diagram. > But if you were architecting the system for voice recognition, then there > would be no debate whatsoever. To enable voice recognition, you will > definitely need an in band solution! The advantage of the above diagram is > thus obvious: designing the call flows for in-band carrying of DTMF enables > us to use the same flows for DTMF and voice recognition. Of course, if you're talking about in-band voice recognition which is monitoring a call, you're begging the privacy question. I might want my LindaTripper to listen in, but I sure don't want yours... or worse, a service provider's! Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 12:45:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08643 for ; Tue, 11 Jul 2000 12:45:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 334E744412; Tue, 11 Jul 2000 12:39:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 81E3E443F5 for ; Tue, 11 Jul 2000 12:39:05 -0400 (EDT) Received: from dynamicsoft.com (1Cust248.tnt2.freehold.nj.da.uu.net [63.17.114.248]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA10109; Tue, 11 Jul 2000 12:40:27 -0400 (EDT) Message-ID: <396B4E57.CE19EF1B@dynamicsoft.com> Date: Tue, 11 Jul 2000 12:41:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: <2E3FA0558747934A8F753CC533A3F6DF01FF5836@red-msg-24.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > > +-----------+ > > > | media | > > > | server | > > > | | x control > > > +-----------+ xx > > > x > > > . x > > > . +---------+ > > > . | app | > > > . | server | \ > > > RTP. / | | \ > > > . / +---------+ \ SIP > > > . / \ > > > . / SIP \ > > > . / +-------+ > > > +-------+ | | > > > | | | | > > > | | | UAS | > > > | UAC |...................... | | > > > | | | | > > > +-------+ RTP +-------+ > > I would add one point. We are in year 2000, not 1980. Engineering for DTMF > is fine, but the next release of the "media server" in the above picture is > likely to use voice recognition, not DTMF. There have always be two camps > when it comes to carrying DTMF, in-band as in the RTP solution detailed > above, and out of band through the signalling channel, as proposed many > times. The two camps have been resorting to all kinds of comparison, > essentially balancing transmission overhead, which is lower in the > out-of-band scenario, and architecture simplicity, as in the above diagram. > But if you were architecting the system for voice recognition, then there > would be no debate whatsoever. To enable voice recognition, you will > definitely need an in band solution! Agree 100%. Furthermore, once you do that, you'd really like your system not to look or work fundamentally differently if speech recognition is used as opposed to DTMF. Having them both come through the same, in-band stream provides this uniformity of interface. In fact, if the DTMF was carried through INFO, it would be difficult to write scripted applications (ala VoiceXML), since then the app server would sometimes need to handle the user input component of the script (when DTMF over SIP was used), and other times not (when speech recongition is used). Very bad. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 12:50:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08917 for ; Tue, 11 Jul 2000 12:50:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4DA444420; Tue, 11 Jul 2000 12:47:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 22D95443EE for ; Tue, 11 Jul 2000 12:47:16 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TL383>; Tue, 11 Jul 2000 09:47:11 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE67A905@sd_exchange.nuera.com> From: "Bratakos, Maroula" To: "'Michelle.Kitchings@ericsson.com'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: SIP digest, Vol 1 #180 - 7 msgs Date: Tue, 11 Jul 2000 09:47:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This requires that the UAC have the smarts to know that it was previously connected to some sort of an application server and that it must reconnect after it sends a BYE to the UAS. I don't think that the UAC should have to know, based on a number a user dialed, whether the (initial) destination is an application server that will require re-connection when the call is over. Regards, Maroula Bratakos -----Original Message----- From: Michelle Kitchings [mailto:Michelle.Kitchings@exu.ericsson.se] Sent: Tuesday, July 11, 2000 9:37 AM To: sip@lists.bell-labs.com Subject: [SIP] Re: SIP digest, Vol 1 #180 - 7 msgs Ok, I'll take a shot at this... In Jonathon's architecture, once the RTP is established between the UAC & UAS, yes, the UAC can break the connection to the media server. Later, when the UAC gets an indication from the user to terminate the current call (UAC-UAS), it will send a BYE to the UAS. At that point, the UAC can re-establish a connection to the media server to monitor for the long '#' and start over with prompt/collect. If no '#' is received after X amount of seconds, the UAC-Media connection is terminated and the pre-paid call is over. There is no reason I can see why the '#' digit has to be collected while the UAC-UAS connection is still ongoing. Cheers, Michelle Kitchings > > Subject: RE: [SIP] DTMF digit handling > Date: Tue, 11 Jul 2000 08:29:43 -0700 (PDT) > From: Michael Thomas > To: "Girzon, Gary" > CC: "'Jonathan Rosenberg'" , > "'sip@lists.bell-labs.com'" > References: <2CC2CB3C95C3D311ABAC009027DCD77E0AB9C0@wks194.pactolus.com> > > > Assuming the UAC is sending named signaling events, > it seems to me that it's six of one, half dozen of > the other of whether the media server monitors the > call for more digits using RTP or SIP INFO methods. > Given that the media server needs to deal with things > like duration (ie long #), NSE's seem like a lot better > approach, and to my mind fits the SIP architecture a > whole lot better: SIP's good at initiating media > streams; it's pretty lousy at being a device control > protocol. Essentially it's just a DTMF multiparty > conference. > > Mike > > Subject: RE: [SIP] DTMF digit handling > Date: Tue, 11 Jul 2000 11:28:12 -0400 > From: "Girzon, Gary" > To: "'Jonathan Rosenberg'" > CC: "'sip@lists.bell-labs.com'" > > I don't have any issues with the architecture below or > the call flow. Yes, the Media Server initially collects DTMF information > directly via RTP but once the RTP connection between UAS > and UAC is set up, there is no need for the UAC - Media Server > RTP connection. Maintaining the RTP connection just for DTMF > digit collection (required to collect the long # and any > others) is really a waste of resources on the Media Server, > not to mention extra bandwidth. Typically, there is 1:7 mapping > of Media Server to Caller resources - i.e., the Media Server > plays a prompt, collects a few digits and then dis-engages. > That Media Server port can be re-used for other Media > Applications. Once the Caller hits #, the Media Server gets > reconnected, plays prompts and collects digits again. > > So the real question is how to collect the long # and any > any other DTMF while UAC and UAS are connected. This is > where I think SIP INFO method provides a good solution. > Does anyone have another method of sending DTMF information > from UAC not requiring an RTP connection to the Media Server? > > As for the protocol between the App Server and Media Server, > that's a whole other discussion... > > Gary Girzon ... > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, July 11, 2000 1:26 AM > > To: Girzon, Gary > > Cc: 'Henning Schulzrinne'; Culpepper, Bert; Michael Thomas; Igor > > Slepchin; Shankar, Krishnakumar; 'sip@lists.bell-labs.com' > > Subject: Re: [SIP] DTMF digit handling > > > > Part of the confusion are the different pictures people have in their > > heads about the architecture for providing these services. > > Pre-paid is a > > classic example of an app where the media stream must be > > terminated by a > > SIP UA anyway, for generating prompts and the like. Let me draw a > > picture of how I view this service being architected: > > > > > > +-----------+ > > | media | > > | server | > > | | x control > > +-----------+ xx > > x > > . x > > . +---------+ > > . | app | > > . | server | \ > > RTP. / | | \ > > . / +---------+ \ SIP > > . / \ > > . / SIP \ > > . / +-------+ > > +-------+ | | > > | | | | > > | | | UAS | > > | UAC |...................... | | > > | | | | > > +-------+ RTP +-------+ > > > > The UAC makes a call (a gateway, typically), and its SIP > > INVITE arrives > > at an app server handling the pre-paid calling application. > > Using 3pcc, > > this app server sends a 183, and includes in it SDP > > corresponding to the > > address of some media server. The media server terminates the RTP from > > the UAC; its the one thats going to play the prompts and extract DTMF. > > Now, once the credit card information has been collected, you'd like > > that information to be sent back to the app server via some control > > protocol, X, to be determined. Once thats done, the app > > server sends the > > INVITE the the UAS, which sends 200 OK, and the UAC now sends RTP > > directly to the UAS. > > > > In this model, the app server never sees media. Media is > > always directly > > sent between the entities communicating. There are no extra delays. We > > do not need DTMF in SIP, since the media server is terminating and > > originating RTP. > > > > What we do need is some sort of control protocol between the > > app server > > and the media server. This would be used to control the IVR prompts, > > collect the credit card, and get it back. Many people like megaco/mgcp > > here. I, frankly, much prefer VoiceXML as it is oodles easier > > to program > > and plays very nicely with SIP. Anyway, whatever it is, that control > > protocol reports the DTMF as needed. Note that this interface is NOT > > SIP. > > > > If someone has a different architecture in mind for this > > service, speak > > up. > > > > -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 Tue Jul 11 15:05:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16158 for ; Tue, 11 Jul 2000 15:05:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C21E4434F; Tue, 11 Jul 2000 15:04:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id EE0C84433E for ; Tue, 11 Jul 2000 15:04:41 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA16515; Tue, 11 Jul 2000 12:04:54 -0700 (PDT) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAA20266; Tue, 11 Jul 2000 12:04:39 -0700 (PDT) Message-Id: <4.2.0.58.20000711120236.00d83430@lint.cisco.com> X-Sender: rmahy@lint.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 11 Jul 2000 12:03:54 -0700 To: sip@lists.bell-labs.com From: Rohan Mahy Cc: islain@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] new ID for SIP message waiting Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Ilya Slain and I have just submitted an ID for SIP Message Waiting. Until it appear in the archives, it is available at: ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-message-waiting-00.txt thanks, -rohan Rohan Mahy and Ilya Slain (islain@cisco.com) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 15:30:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17236 for ; Tue, 11 Jul 2000 15:30:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 90FDC443AD; Tue, 11 Jul 2000 15:30:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from empowertel.com (unknown [64.220.200.243]) by lists.bell-labs.com (Postfix) with ESMTP id D2FBE44372 for ; Tue, 11 Jul 2000 15:30:09 -0400 (EDT) Received: from Rajeev ([192.168.111.39]) by empowertel.com (8.9.3+Sun/8.9.3) with SMTP id MAA25246 for ; Tue, 11 Jul 2000 12:27:58 -0700 (PDT) Reply-To: From: "Rajeev Gupta" To: Subject: RE: [SIP] DTMF digit handling Date: Tue, 11 Jul 2000 12:27:25 -0700 Message-ID: <009001bfeb6e$0babc680$276fa8c0@empowertel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <2E3FA0558747934A8F753CC533A3F6DF01FF5836@red-msg-24.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit To Christian's point: > I would add one point. We are in year 2000, not 1980. Engineering for DTMF > is fine, but the next release of the "media server" in the above picture is > likely to use voice recognition, not DTMF. There is a whole class of voice-activated applications that can be enabled with IP voice. Essentially, the ingress gateway will multi-unicast the media stream - one stream going to the current callee, other streams going to multiple media servers (speech recognition, IVR,...). Note that different sampling rates, codecs and other voice processing can be used on different streams. For example, "voice dialing" can be enabled by allowing the user to speak certain keywords (as opposed to punching a long '#') which the media server will recognize, and switch the call to a differnt call/service e.g. speaking "keyword-XXX Dial 555-1212" will connect to new number 555-1212. Note that the media stream for keyword recognition can be much more sparse than the one for voice conversation e.g. only speech samples after certain silence periods need be transmitted on this stream. Further, the media server does not have to be contiuously "connected" to this media stream, since it is not a TDM port, and hence the media server resources can be shared very effectively among multiple users. With this architecture, service providers can enable fancy services like voice dialing for a fraction of the cost in a TDM architecture. As for privacy concerns, you can choose whether you want this service or not (no different than today's calling card applications). Rajeev Gupta empowerTel Networks 475 Sycamore Drive, Milpitas, CA 95035 Phone: +1 408 519 7136 Fax: +1 408 519 7399 mailto:rajeev@empowertel.com http://www.empowertel.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 Jul 11 16:17:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18577 for ; Tue, 11 Jul 2000 16:17:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCD4F44354; Tue, 11 Jul 2000 16:17:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8D86F44349 for ; Tue, 11 Jul 2000 16:17:15 -0400 (EDT) Received: from dynamicsoft.com (1Cust248.tnt2.freehold.nj.da.uu.net [63.17.114.248]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA11744; Tue, 11 Jul 2000 16:18:10 -0400 (EDT) Message-ID: <396B815A.9D75B92B@dynamicsoft.com> Date: Tue, 11 Jul 2000 16:19:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Cc: SIP Subject: Re: [SIP] 415 Unsupported Media Type References: <14699.15965.59567.455952@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit It doesn't work that way. You should not get a "new" SDP in the ACK. SDP goes in ACK only if there was no SDP in INVITE, then SDP was included in the 200 OK. This SDP should represent a subset of the media "offered" in the 200 OK. In other words, a normal SIP transaction has one SDP in the INVITE, and another in 200 OK. Now, we have the same two phase process, but the first SDP is in the 200 OK, and the second in the ACK. -Jonathan R. Dvir Oren wrote: > > If I get a new SDP body in the ACK, and I don't like the media type, > how can I reply that the media type is unacceptable to me? > > -- > Dvir Oren > Lucid VON Ltd. > 9 Saloniki St., Tel-Aviv Israel > Tel: +972 3 644 3038 Fax: +972 3 644 3039 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 16:31:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18850 for ; Tue, 11 Jul 2000 16:31:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 25363443DB; Tue, 11 Jul 2000 16:31:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from showboat.teradyne.com (unknown [198.51.251.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6891944382 for ; Tue, 11 Jul 2000 16:31:28 -0400 (EDT) Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195]) by showboat.teradyne.com (8.8.8+Sun/8.8.8) with ESMTP id QAA18005 for ; Tue, 11 Jul 2000 16:29:45 -0400 (EDT) Received: from notes.teradyne.com (jaypeak.corp.teradyne.com [131.101.17.23]) by chorus.teradyne.com (8.8.8+Sun/8.7.1) with SMTP id QAA12411 for ; Tue, 11 Jul 2000 16:31:23 -0400 (EDT) Received: by notes.teradyne.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 85256919.0071028C ; Tue, 11 Jul 2000 16:34:22 -0400 X-Lotus-FromDomain: TERADYNE From: "Kevin Davis" To: sip@lists.bell-labs.com Message-ID: <85256919.0071009F.00@notes.teradyne.com> Date: Tue, 11 Jul 2000 16:35:37 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] DTMF and voice-over-packet Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > I would add one point. We are in year 2000, not 1980. Engineering for DTMF > is fine, but the next release of the "media server" in the above picture > is likely to use voice recognition, not DTMF. Although speech recognition may replace DTMF in some applications, support for DTMF will continue to be required for decades to come. In any environment where others can overhear you, do you really want to speak your PIN or password into a phone? I don't think so. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 17:01:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20108 for ; Tue, 11 Jul 2000 17:01:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C4F5443DE; Tue, 11 Jul 2000 17:00:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by lists.bell-labs.com (Postfix) with ESMTP id 8A4CE4438A for ; Tue, 11 Jul 2000 17:00:31 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id RAA10853; Tue, 11 Jul 2000 17:00:25 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Kevin Davis'" , Subject: RE: [SIP] DTMF and voice-over-packet Date: Tue, 11 Jul 2000 17:00:23 -0400 Message-ID: <001201bfeb7b$08f2d520$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-To: <85256919.0071009F.00@notes.teradyne.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Kevin Davis > > I would add one point. We are in year 2000, not 1980. > Engineering for DTMF > > is fine, but the next release of the "media server" in the > above picture > > is likely to use voice recognition, not DTMF. > > > Although speech recognition may replace DTMF in some applications, > support for DTMF will continue to be required for decades to come. > In any environment where others can overhear you, do you really > want to speak your PIN or password into a phone? I don't think so. Hi Kevin, You are right. Whenever, I dial into systems that give me choice of saying "one" or pressing "1", guess what I do - I almost always press "1". I believe that most people like to press "4""5""3""7" than say "four five three seven", and would continue to do the same for years to come. It is not just security - it is security plus convenience. I guess that DTMF will be used even in year 2020. Cheers, --brijesh Ennovate Networks 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 Jul 11 17:45:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21478 for ; Tue, 11 Jul 2000 17:45:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4705A443F0; Tue, 11 Jul 2000 17:45:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id D2F554438A for ; Tue, 11 Jul 2000 17:45:09 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id RAA11990; Tue, 11 Jul 2000 17:44:53 -0400 (EDT) Message-ID: <396B9555.3E6D9290@cisco.com> Date: Tue, 11 Jul 2000 17:44:53 -0400 From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: byerly@cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Computing SIP-URL from TEL-URL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi guys, From a SIP proxy's perspective, Can anyone think of a reason that it would not be safe to assume that a TEL-URL: tel:5551234 is equivalent to the SIP-URL: sip:5551234@this_proxy;user=phone where "this_proxy" is the IP address of the proxy processing the message. Is this assumption safe for all known headers ("To:", "From:", "Contact:", "Route:", "Remote-Party-ID", ...)? Thanks! Bryan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 18:21:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22038 for ; Tue, 11 Jul 2000 18:21:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5ADB443F7; Tue, 11 Jul 2000 18:21:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7]) by lists.bell-labs.com (Postfix) with ESMTP id B2D6E44354 for ; Tue, 11 Jul 2000 18:21:33 -0400 (EDT) Received: from luan (a98.vovida.com [209.237.8.98] (may be forged)) by illustrious.cnchost.com id SAA18652; Tue, 11 Jul 2000 18:21:05 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Reply-To: From: "Luan Dang" To: , "'Kevin Davis'" , Subject: RE: [SIP] DTMF and voice-over-packet Date: Tue, 11 Jul 2000 15:21:55 -0700 Message-ID: <004b01bfeb86$6bdaa720$2a05a8c0@private.vovida.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <001201bfeb7b$08f2d520$d001010a@tst.ennovatenetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Brijesh Kumar wrotes: > Hi Kevin, > > You are right. > > Whenever, I dial into systems that give me choice of saying "one" or > pressing "1", guess what I do - I almost always press "1". I believe > that most people like to press "4""5""3""7" than say "four five three > seven", and would continue to do the same for years to come. It is not > just security - it is security plus convenience. I guess that DTMF > will be used even in year 2020. > > Cheers, > > --brijesh > Ennovate Networks Inc. > Brijesh, You are missing the bigger picture. In the future you will not have to say "one", "two"..., you can simply ask for what you want. This is the by product of current DTMF design. On security, there are many different methods including speech authentication and time sensitive pin code that would not matter if someone over heard you. I sure hope we will not be using DTMF in year 2020. -- Luan Dang Senior VP & CTO mailto:ldang@vovida.com Vovida Networks, Inc. voice:(408)383-1060 http://www.vovida.com fax:(408)383-1062 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 18: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 ESMTP id SAA22641 for ; Tue, 11 Jul 2000 18:57:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D43344407; Tue, 11 Jul 2000 18:57:12 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail-dns1-nj.dialogic.com (mail-dns1-nj.dialogic.com [146.152.228.10]) by lists.bell-labs.com (Postfix) with ESMTP id C912944369 for ; Tue, 11 Jul 2000 18:57:08 -0400 (EDT) Received: from mail4.dialogic.com ([146.152.6.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: dialogic.m4,v 1.3 2000/05/05 13:56:23 dmccart Exp $) with ESMTP id WAA11510; Tue, 11 Jul 2000 22:59:29 GMT Received: from sanmiguel.dialogic.com (sanmiguel.dialogic.com [146.152.131.2]) by mail4.dialogic.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27017; Tue, 11 Jul 2000 18:56:24 -0400 (EDT) Received: from 100grand (dhcp06.sb.dialogic.com [146.152.131.156]) by sanmiguel.dialogic.com (8.9.3+Sun/8.9.1) with SMTP id PAA03995; Tue, 11 Jul 2000 15:56:23 -0700 (PDT) From: "Jeff Mark" To: , , "'Kevin Davis'" , Subject: RE: [SIP] DTMF and voice-over-packet Date: Tue, 11 Jul 2000 15:56:50 -0700 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <004b01bfeb86$6bdaa720$2a05a8c0@private.vovida.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Check out United Airlines automated flight info line for an example application that does not use DTMF. Take a test drive by calling 1-800-824-6200. -Jeff Dialogic, an Intel Company From: Luan Dang [mailto:ldang@vovida.com] > > Brijesh Kumar wrotes: > > Hi Kevin, > > > > You are right. > > > > Whenever, I dial into systems that give me choice of saying "one" or > > pressing "1", guess what I do - I almost always press "1". I believe > > that most people like to press "4""5""3""7" than say "four five three > > seven", and would continue to do the same for years to come. It is not > > just security - it is security plus convenience. I guess that DTMF > > will be used even in year 2020. > > > > Cheers, > > > > --brijesh > > Ennovate Networks Inc. > > > Brijesh, > > You are missing the bigger picture. In the future you will not have > to say "one", "two"..., you can simply ask for what you want. This is > the by product of current DTMF design. > On security, there are many different methods including speech > authentication and time sensitive pin code that would not matter if > someone over heard you. > I sure hope we will not be using DTMF in year 2020. > > -- > Luan Dang > Senior VP & CTO mailto:ldang@vovida.com > Vovida Networks, Inc. voice:(408)383-1060 > http://www.vovida.com fax:(408)383-1062 > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 19:05:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22796 for ; Tue, 11 Jul 2000 19:05:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5833944414; Tue, 11 Jul 2000 19:05:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by lists.bell-labs.com (Postfix) with ESMTP id 296C144369 for ; Tue, 11 Jul 2000 19:05:05 -0400 (EDT) Received: from radvision.com ([38.150.216.6]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000711230504.JNMM1469.hvmta01-stg@radvision.com>; Tue, 11 Jul 2000 19:05:04 -0400 Message-ID: <396BA8DC.F6937D38@radvision.com> Date: Tue, 11 Jul 2000 19:08:12 -0400 From: Anatoli Levine Organization: RADVision Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Jeff Mark Cc: ldang@vovida.com, bkumar@ennovatenetworks.com, "'Kevin Davis'" , sip@lists.bell-labs.com Subject: Re: [SIP] DTMF and voice-over-packet References: Content-Type: multipart/mixed; boundary="------------1C85DE3D211AB4E7218F658F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------1C85DE3D211AB4E7218F658F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff, well, the this was rather an example of a bad interface - you can still use DTMF to get the flight info, but in some cases only after the system fails with the voice response... We are talking convenience here, so even in 2020 we will have some things which will be easier and faster to type (DTMF) than to say... Anatoli Jeff Mark wrote: > Check out United Airlines automated flight info line for an example > application that does not use DTMF. Take a test drive by calling > 1-800-824-6200. > > -Jeff > Dialogic, an Intel Company > > From: Luan Dang [mailto:ldang@vovida.com] > > > > Brijesh Kumar wrotes: > > > Hi Kevin, > > > > > > You are right. > > > > > > Whenever, I dial into systems that give me choice of saying "one" or > > > pressing "1", guess what I do - I almost always press "1". I believe > > > that most people like to press "4""5""3""7" than say "four five three > > > seven", and would continue to do the same for years to come. It is not > > > just security - it is security plus convenience. I guess that DTMF > > > will be used even in year 2020. > > > > > > Cheers, > > > > > > --brijesh > > > Ennovate Networks Inc. > > > > > Brijesh, > > > > You are missing the bigger picture. In the future you will not have > > to say "one", "two"..., you can simply ask for what you want. This is > > the by product of current DTMF design. > > On security, there are many different methods including speech > > authentication and time sensitive pin code that would not matter if > > someone over heard you. > > I sure hope we will not be using DTMF in year 2020. > > > > -- > > Luan Dang > > Senior VP & CTO mailto:ldang@vovida.com > > Vovida Networks, Inc. voice:(408)383-1060 > > http://www.vovida.com fax:(408)383-1062 > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------1C85DE3D211AB4E7218F658F Content-Type: text/x-vcard; charset=us-ascii; name="alevine.vcf" Content-Description: Card for Anatoli Levine Content-Disposition: attachment; filename="alevine.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Levine;Anatoli x-mozilla-html:FALSE org:RADVision Inc. adr:;;575 Corporate Drive, Suite 420;Mahwah;NJ;07430;USA version:2.1 email;internet:alevine@radvision.com title:Director, Software Support tel;fax:(201) 529-3516 tel;work:(201) 529-4300, x244 x-mozilla-cpt:;0 fn:Anatoli Levine end:vcard --------------1C85DE3D211AB4E7218F658F-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 19:14:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22900 for ; Tue, 11 Jul 2000 19:14:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F210C44425; Tue, 11 Jul 2000 19:13:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 72A74443CA for ; Tue, 11 Jul 2000 19:13:19 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA13152; Tue, 11 Jul 2000 19:14:47 -0400 (EDT) Message-ID: <396BAA08.3C1B174A@dynamicsoft.com> Date: Tue, 11 Jul 2000 19:13:12 -0400 From: Igor Slepchin Organization: dynamicsoft Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Bryan Byerly Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Computing SIP-URL from TEL-URL References: <396B9555.3E6D9290@cisco.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Bryan Byerly wrote: > > >From a SIP proxy's perspective, > > Can anyone think of a reason that it would not be safe to assume that a > TEL-URL: > tel:5551234 > is equivalent to the SIP-URL: > sip:5551234@this_proxy;user=phone Well, they are two different URLs and may or may not refer to the same resource. Proxies may (or may not) treat them differently. E.g., a proxy may consider sip:5551234@this_proxy;user=phone to be a valid username in its address space (user=phone notwithstanding), look for registrations for that user and forward the request to the registered hosts. > Is this assumption safe for all known headers ("To:", "From:", > "Contact:", "Route:", "Remote-Party-ID", ...)? Note that only SIP URLs are allowed in Contact and Route headers. Both Contact and Route are used for forwarding SIP messages and tel URLs don't make sense in that context. 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 Jul 11 20:14:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23873 for ; Tue, 11 Jul 2000 20:14:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A0C1443ED; Tue, 11 Jul 2000 20:14:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E5E1A44348 for ; Tue, 11 Jul 2000 20:14:06 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA01098; Tue, 11 Jul 2000 20:14:05 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA19913; Tue, 11 Jul 2000 18:33:45 -0400 (EDT) Message-ID: <396BA0C9.BBB006ED@cs.columbia.edu> Date: Tue, 11 Jul 2000 18:33:45 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ldang@vovida.com Cc: bkumar@ennovatenetworks.com, "'Kevin Davis'" , sip@lists.bell-labs.com Subject: Re: [SIP] DTMF and voice-over-packet References: <004b01bfeb86$6bdaa720$2a05a8c0@private.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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Luan Dang wrote: > > Brijesh Kumar wrotes: > > Hi Kevin, > > > > You are right. > > > > Whenever, I dial into systems that give me choice of saying "one" or > > pressing "1", guess what I do - I almost always press "1". I believe > > that most people like to press "4""5""3""7" than say "four five three > > seven", and would continue to do the same for years to come. It is not > > just security - it is security plus convenience. I guess that DTMF > > will be used even in year 2020. > > > > Cheers, > > > > --brijesh > > Ennovate Networks Inc. > > > Brijesh, > > You are missing the bigger picture. In the future you will not have > to say "one", "two"..., you can simply ask for what you want. This is > the by product of current DTMF design. > On security, there are many different methods including speech > authentication and time sensitive pin code that would not matter if > someone over heard you. > I sure hope we will not be using DTMF in year 2020. > In 2020, your universal communicator will recognize you by using its camera to look into your eyes and do a retina scan (particularly if the display is integrated into your glasses or contact lenses) or recognize you when you place your finger on the gadget, via fingerprint recognition. -- 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 Jul 11 20:30:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24059 for ; Tue, 11 Jul 2000 20:30:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78A724442C; Tue, 11 Jul 2000 20:29:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ami4000.hei.co.kr (unknown [202.30.128.31]) by lists.bell-labs.com (Postfix) with ESMTP id 363B34441B for ; Tue, 11 Jul 2000 20:29:43 -0400 (EDT) Received: from hei.co.kr ([166.125.19.48]) by ami4000.hei.co.kr (8.9.3/8.9.3) with ESMTP id JAA19345 for ; Wed, 12 Jul 2000 09:27:30 +0900 (KST) Message-ID: <396BBBDB.4314302A@hei.co.kr> Date: Wed, 12 Jul 2000 09:29:16 +0900 From: Junghwa Ye Organization: Hyundai Electronics X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------981F66ECDAB033F74B158FA2" Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------981F66ECDAB033F74B158FA2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit confirm 517150 --------------981F66ECDAB033F74B158FA2 Content-Type: text/x-vcard; charset=us-ascii; name="jupiter.vcf" Content-Description: Card for Junghwa Ye Content-Disposition: attachment; filename="jupiter.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Ye;Junghwa tel;cell:82-018-330-9887 tel;fax:82-2-580-5437 tel;home:82-2-580-5397 x-mozilla-html:FALSE org:Hyundai Electronics;3G System Technology Research Team version:2.1 email;internet:jupiter@hei.co.kr title:Research Engineer adr;quoted-printable:;;Daeho Bldg.=0D=0A1451-34, Seocho-dong, Seocho-ku, Seoul, Korea=0D=0A137-070;;;; fn:Junghwa Ye end:vcard --------------981F66ECDAB033F74B158FA2-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 20:41:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24263 for ; Tue, 11 Jul 2000 20:41:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37B8044437; Tue, 11 Jul 2000 20:40:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id A8BC14441A for ; Tue, 11 Jul 2000 20:40:37 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TLPG3>; Tue, 11 Jul 2000 17:40:33 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8A85@sd_exchange.nuera.com> From: "Fox, Mike" To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Date: Tue, 11 Jul 2000 17:40:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: Tunneling with SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Jonathan Rosenberg wrote: > I would not advocate tunneling DHCP over SIP, HTTP over SIP, > or SLP over > SIP, since those protocols > don't do the same thing SIP does. Same with megaco/mgcp. > Tunneling them > over SIP serves no purpose. SIP is not a good transfer > protocol (see the > Guidelines for Authors of SIP Extensions: > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-gui >delines-00.txt). >Just use the native transport define by the protocol. Perhaps it would be too simple an extrapolation to conclude that you are not in favor of ... http://www.ietf.org/internet-drafts/draft-deason-sip-soap-00.txt Could you share your opinion? (I would mine, but few care about it! ;-) Best regards, Mike Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 20:59:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24464 for ; Tue, 11 Jul 2000 20:59:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CEC744443D; Tue, 11 Jul 2000 20:59:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from showboat.teradyne.com (unknown [198.51.251.10]) by lists.bell-labs.com (Postfix) with ESMTP id 2551344336 for ; Tue, 11 Jul 2000 20:59:29 -0400 (EDT) Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195]) by showboat.teradyne.com (8.8.8+Sun/8.8.8) with ESMTP id UAA21558 for ; Tue, 11 Jul 2000 20:57:22 -0400 (EDT) Received: from notes.teradyne.com (jaypeak.corp.teradyne.com [131.101.17.23]) by chorus.teradyne.com (8.8.8+Sun/8.7.1) with SMTP id UAA19310 for ; Tue, 11 Jul 2000 20:59:00 -0400 (EDT) Received: by notes.teradyne.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8525691A.0005AF27 ; Tue, 11 Jul 2000 21:02:05 -0400 X-Lotus-FromDomain: TERADYNE From: "Kevin Davis" To: sip@lists.bell-labs.com Message-ID: <8525691A.0005AE4B.00@notes.teradyne.com> Date: Tue, 11 Jul 2000 21:03:36 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] summary: DTMF and voice-over-packet Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com (Hoping to cut short yet another rampant deteriorating discussion thread, I here attempt to summarize.) It is necessary to support applications based upon DTMF and also applications based upon speech recognition Thinking-outside-the-box visions for the year 2020 are good, but let us not loose sight of the years 2001-2019. 1) Many applications, both current and future, are better enabled through speech recognition (instead of DTMF) 2) Some applications are better served by non-verbal keypad input. It can be readily argued that the standard 12-button telephone keypad will persist for a significant number of years to come; though it it may someday go the way of rotary-dial phones. 3) In cases where both interfaces are feasible, different users may prefer one over the other 4) Today, the telephone keypad interface is linked to DTMF. If or when this relationship should change is another matter. If it should change, it is still important to maintain compatibility with a huge installed base of DTMF. > > It is not just security - it is security plus convenience. > > I guess that DTMF will be used even in year 2020. > >You are missing the bigger picture. In the future you will not have >to say "one", "two"..., you can simply ask for what you want. This >>is the by product of current DTMF design. >On security, there are many different methods including speech >authentication and time sensitive pin code that would not matter if >someone over heard you. >I sure hope we will not be using DTMF in year 2020. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 21: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 ESMTP id VAA24550 for ; Tue, 11 Jul 2000 21:01:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57CEA4444F; Tue, 11 Jul 2000 21:00:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by lists.bell-labs.com (Postfix) with ESMTP id 47B5B44444 for ; Tue, 11 Jul 2000 20:59:59 -0400 (EDT) Received: from vovida.com (a98.vovida.com [209.237.8.98] (may be forged)) by repulse.cnchost.com id UAA15949; Tue, 11 Jul 2000 20:59:58 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] From: skumar@vovida.com Message-ID: <396BC311.CCDFCFF3@vovida.com> Date: Tue, 11 Jul 2000 18:00:01 -0700 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] Clarification on SDP in other msgs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit for placing media streams on hold, normally, the INVITE has its SDP information set to zero. Can this be used in the responses too, i.e the 200 OK messages. Or, does this have some other implication. thanks much. sunitha _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 21:28:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24772 for ; Tue, 11 Jul 2000 21:28:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2EF4A443D1; Tue, 11 Jul 2000 21:27:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 7AB2744336 for ; Tue, 11 Jul 2000 21:27:28 -0400 (EDT) Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA16642 for ; Tue, 11 Jul 2000 18:27:36 -0700 (PDT) Date: Tue, 11 Jul 2000 21:27:08 -0400 (EDT) From: David Williams To: sip@lists.bell-labs.com Subject: [SIP] Stateless Redirect Server? In-Reply-To: <396BAA08.3C1B174A@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Overall, it appears that Redirect servers should behave statefully and retransmit their final response. But is it also legal for them to behave statelessly and only send a single final response? In a manner similiar to that of a stateless proxy? Some relevant sections of the 2453bis: Section 12.1 (Behavior of Redirect Servers) says: "The Redirect server maintains transaction state for the whole SIP transaction." Section 10.1.2 (Responses) says: "Responses with status 300 and higher are retransmitted by each stateful proxy or UAS until the next upstream proxy or UAC sends an ACK or CANCEL." But no meantion of a redirect server. Section 10.5.1 (UDP) indicates that servers should reliably retransmit responses. Without meantioning that stateless proxies cannot. thanks, -david _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 21:47:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25970 for ; Tue, 11 Jul 2000 21:47:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5276144444; Tue, 11 Jul 2000 21:46:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lists.bell-labs.com (Postfix) with SMTP id A6B1E4441A for ; Tue, 11 Jul 2000 21:46:48 -0400 (EDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Jul 2000 18:45:01 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id <3X64MB5S>; Tue, 11 Jul 2000 18:44:35 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01FF583F@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Kevin Davis'" , sip@lists.bell-labs.com Subject: RE: [SIP] summary: DTMF and voice-over-packet Date: Tue, 11 Jul 2000 18:44:31 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > From: Kevin Davis [mailto:Kevin_Davis@notes.teradyne.com] > ... > 4) Today, the telephone keypad interface is linked to DTMF. > If or when this relationship should change is another > matter. If it should change, it is still important to > maintain compatibility with a huge installed base of DTMF. Nobody is proposing to cut support for DTMF. The argument is that, out of two ways to support DTMF, the out of band solutions that include DTMF translations in the signalling channel don't carry over to voice recognition, while the in band solutions that establish a specific RTP leg to the DTMF handler also work for voice recognition. Ergo, we should consider that the "DTMF in RTP" solution is adequate and stop worrying about the addition of DTMF verbs, or parameters, in SIP itself. Christian Huitema _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 23:29:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28066 for ; Tue, 11 Jul 2000 23:29:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A254844370; Tue, 11 Jul 2000 23:29:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 2A39A44341 for ; Tue, 11 Jul 2000 23:29:16 -0400 (EDT) Received: from flyer (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id JAA13248 for ; Wed, 12 Jul 2000 09:32:06 -0500 From: "Dean Willis" To: "IETF SIP" Date: Tue, 11 Jul 2000 22:30:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [SIP] Web Page tracking IETF 48 SIP WG Agenda Requests Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I am tracking agenda requests for the SIP WG at: http://www.softarmor.com/sipwg/meets/IETF48/requests.html If you've made a request and it isn't listed, make a request and it doesn't get listed in a timely fashion, or need to make a request, please feel free to contact me directly. An agenda will take place in the same basic area of the web as we get to that point. -- 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 Tue Jul 11 23:42:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28600 for ; Tue, 11 Jul 2000 23:42:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6EB1A443B5; Tue, 11 Jul 2000 23:42:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 45A7044373 for ; Tue, 11 Jul 2000 23:41:58 -0400 (EDT) Received: from dynamicsoft.com (1Cust248.tnt2.freehold.nj.da.uu.net [63.17.114.248]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA13666; Tue, 11 Jul 2000 23:43:23 -0400 (EDT) Message-ID: <396BE9AD.A0DDA212@dynamicsoft.com> Date: Tue, 11 Jul 2000 23:44:45 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema Cc: "'Kevin Davis'" , sip@lists.bell-labs.com Subject: Re: [SIP] summary: DTMF and voice-over-packet References: <2E3FA0558747934A8F753CC533A3F6DF01FF583F@red-msg-24.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > From: Kevin Davis [mailto:Kevin_Davis@notes.teradyne.com] > > ... > > 4) Today, the telephone keypad interface is linked to DTMF. > > If or when this relationship should change is another > > matter. If it should change, it is still important to > > maintain compatibility with a huge installed base of DTMF. > > Nobody is proposing to cut support for DTMF. The argument is that, out of > two ways to support DTMF, the out of band solutions that include DTMF > translations in the signalling channel don't carry over to voice > recognition, while the in band solutions that establish a specific RTP leg > to the DTMF handler also work for voice recognition. Ergo, we should > consider that the "DTMF in RTP" solution is adequate and stop worrying about > the addition of DTMF verbs, or parameters, in SIP itself. Exactly. Well said. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 23:47:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28691 for ; Tue, 11 Jul 2000 23:47:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C2C83443EA; Tue, 11 Jul 2000 23:46:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5094044373 for ; Tue, 11 Jul 2000 23:46:49 -0400 (EDT) Received: from dynamicsoft.com (1Cust248.tnt2.freehold.nj.da.uu.net [63.17.114.248]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA13674; Tue, 11 Jul 2000 23:48:18 -0400 (EDT) Message-ID: <396BEAD4.CDEA202E@dynamicsoft.com> Date: Tue, 11 Jul 2000 23:49:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fox, Mike" Cc: sip@lists.bell-labs.com References: <613A6A6A3F09D3118F5C00508B2C24FEAD8A85@sd_exchange.nuera.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Tunneling with SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Fox, Mike" wrote: > > Jonathan Rosenberg wrote: > > I would not advocate tunneling DHCP over SIP, HTTP over SIP, > > or SLP over > > SIP, since those protocols > > don't do the same thing SIP does. Same with megaco/mgcp. > > Tunneling them > > over SIP serves no purpose. SIP is not a good transfer > > protocol (see the > > Guidelines for Authors of SIP Extensions: > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-gui > >delines-00.txt). > >Just use the native transport define by the protocol. > > Perhaps it would be too simple an extrapolation to conclude that you are not > in favor of ... > http://www.ietf.org/internet-drafts/draft-deason-sip-soap-00.txt > > Could you share your opinion? (I would mine, but few care about it! ;-) I do not believe that SIP is a useful RPC mechanism. None of its user discovery and registration capabilities are needed for RPC, neither are most of its proxy functions. As it is not an ideal transfer protocol, it is not good at carrying serialized objects of any large size. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Jul 11 23:56:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28772 for ; Tue, 11 Jul 2000 23:56:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 763D5443F4; Tue, 11 Jul 2000 23:55:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6E9CA443A6 for ; Tue, 11 Jul 2000 23:55:35 -0400 (EDT) Received: from dynamicsoft.com (1Cust248.tnt2.freehold.nj.da.uu.net [63.17.114.248]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA13699; Tue, 11 Jul 2000 23:57:03 -0400 (EDT) Message-ID: <396BECE1.9AD4E46F@dynamicsoft.com> Date: Tue, 11 Jul 2000 23:58:25 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: skumar@vovida.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Clarification on SDP in other msgs References: <396BC311.CCDFCFF3@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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit skumar@vovida.com wrote: > > for placing media streams on hold, normally, the INVITE has its SDP > information set to zero. > Can this be used in the responses too, i.e the 200 OK messages. Or, > does this have some other implication. Sure. IP address zero always means "don't send me media here right now". -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 00: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 ESMTP id AAA28929 for ; Wed, 12 Jul 2000 00:05:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B5E914443A; Wed, 12 Jul 2000 00:04:34 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 01EEB4434D for ; Wed, 12 Jul 2000 00:04:28 -0400 (EDT) Received: from dynamicsoft.com (1Cust248.tnt2.freehold.nj.da.uu.net [63.17.114.248]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA13735; Wed, 12 Jul 2000 00:05:46 -0400 (EDT) Message-ID: <396BEEEC.C17EFFD6@dynamicsoft.com> Date: Wed, 12 Jul 2000 00:07:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: "Girzon, Gary" , "'Henning Schulzrinne'" , Michael Thomas , Igor Slepchin , "Shankar, Krishnakumar" , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] DTMF digit handling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Culpepper, Bert" wrote: > > The architecture shown matches my view of how a service like pre-paid > calling card would be deployed in a SIP network. The call setup scenario > also matches my view of the signaling. What is not described, > for a service like pre-paid, is how the calling party notifies the app > server > that it wishes to end the current call and originate a second call without > disconnecting completely from the app server and making a new call and > going through the credit card validation a second time. I know we're not > in the PSTN anymore but this is typically done by pressing and holding > the # key for two seconds. > > What appears to be an acceptable solution to mimic this behavior in a SIP > network is to "subscribe" to the DTMF stream (RFC 2833) of the UAC. > The RE-INVITE to the UAC will include two media descriptions in the SDP. > One for the DTMF to be sent to the media server and the second for the > audio to be sent to the UAS. No subscription is needed at all. This is, as you suggest, a simple re-INVITE from the application server to the originating UA, asking to add a media stream. That media stream would be listed as supporting a single codec - dtmf. This would tell the originating UA to send DTMF only to the application server. An app server that does speech recognition would add a media stream that uses a normal codec. Now there are two full media streams, one from the originating UA to the terminating, and another from the originating to the app server. The nice thing here is that this mechanism of using reINVITE to add a media stream is the same for DTMF driven applications and speech recognition. This would not have been the case if INFO was 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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 04:04:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13565 for ; Wed, 12 Jul 2000 04:04:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 70D2D44345; Wed, 12 Jul 2000 04:04:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id B434A44338 for ; Wed, 12 Jul 2000 04:03:58 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA24388; Wed, 12 Jul 2000 09:00:51 +0100 (BST) Message-ID: <396C25B1.8734B64E@ubiquity.net> Date: Wed, 12 Jul 2000 09:00:50 +0100 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "Fox, Mike" , sip@lists.bell-labs.com Subject: Re: [SIP] Re: Tunneling with SIP References: <613A6A6A3F09D3118F5C00508B2C24FEAD8A85@sd_exchange.nuera.com> <396BEAD4.CDEA202E@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > "Fox, Mike" wrote: > > > > Jonathan Rosenberg wrote: > > > I would not advocate tunneling DHCP over SIP, HTTP over SIP, > > > or SLP over > > > SIP, since those protocols > > > don't do the same thing SIP does. Same with megaco/mgcp. > > > Tunneling them > > > over SIP serves no purpose. SIP is not a good transfer > > > protocol (see the > > > Guidelines for Authors of SIP Extensions: > > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-gui > > >delines-00.txt). > > >Just use the native transport define by the protocol. > > > > Perhaps it would be too simple an extrapolation to conclude that you are not > > in favor of ... > > http://www.ietf.org/internet-drafts/draft-deason-sip-soap-00.txt > > > > Could you share your opinion? (I would mine, but few care about it! ;-) I doubt many want mine, but, I'll give it anyway ;^) > > I do not believe that SIP is a useful RPC mechanism. None of its user > discovery and registration capabilities are needed for RPC, neither > are most of its proxy functions. As it is not an ideal transfer > protocol, it is not good at carrying serialized objects of any large > size. There are times however when a RPC may need to be performed in relation to a session and proxies may be interested in the result. I can't believe anyone interested in ushering in the next generation of services couldn't see this. That said as a generic RPC transport mechanism SIP is a very poor choice, and from a security point SOAP is a nightmare (any RPC mechanism designed to breech firewalls without a ALG is a nightmare.) 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 Jul 12 06:33:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15355 for ; Wed, 12 Jul 2000 06:33:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE37D44382; Wed, 12 Jul 2000 06:32:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id CF1CD44345 for ; Wed, 12 Jul 2000 06:32:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15265; Wed, 12 Jul 2000 06:32:27 -0400 (EDT) Message-Id: <200007121032.GAA15265@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Wed, 12 Jul 2000 06:32:27 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-cc-transfer-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Call Control Author(s) : R. Sparks Filename : draft-ietf-sip-cc-transfer-00.txt Pages : 17 Date : 11-Jul-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-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-cc-transfer-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-cc-transfer-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: <20000711135155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-cc-transfer-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-cc-transfer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711135155.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 Jul 12 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 ESMTP id JAA22301 for ; Wed, 12 Jul 2000 09:46:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A1274438A; Wed, 12 Jul 2000 09:46:11 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id CDB3744345 for ; Wed, 12 Jul 2000 09:45:54 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id TAA14153 for ; Wed, 12 Jul 2000 19:15:14 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Wed, 12 Jul 2000 19:15:13 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id TAA22663 for ; Wed, 12 Jul 2000 19:15:12 +0530 (IST) Message-ID: <022801bfec07$4fd2bb40$8c40000a@sasi.com> From: "rafi" To: Date: Wed, 12 Jul 2000 19:14:33 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0225_01BFEC35.6961C460" 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] How to detect interworking ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0225_01BFEC35.6961C460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Is it not useful for a UAC to know whenever there is an interworking taking place (For e.g.=20 SIP-H323)? Is it possible for a "gateway" to=20 indicate such information to UAC? Thank you Rafi Assadi H.M ------=_NextPart_000_0225_01BFEC35.6961C460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
   Is it not useful for a UAC = to know=20 whenever
there is an interworking taking place = (For e.g.=20
SIP-H323)? Is it possible for a = "gateway" to=20
indicate such information to = UAC?
 
Thank you
Rafi Assadi = H.M
------=_NextPart_000_0225_01BFEC35.6961C460-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 09:47:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22390 for ; Wed, 12 Jul 2000 09:47:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A9C644417; Wed, 12 Jul 2000 09:47:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id CB1DF44406 for ; Wed, 12 Jul 2000 09:47:26 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6CDlPM10796 for ; Wed, 12 Jul 2000 15:47:25 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA00551 for ; Wed, 12 Jul 2000 16:47:24 +0300 (EET DST) Message-ID: <396C76D0.52B73701@lmf.ericsson.se> Date: Wed, 12 Jul 2000 16:46:56 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Question about COMET Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, A sends to B an INVITE with SDP preconditions: a=qos:mandatory sendrecv B responses with 183 containing SDP preconditions also: a=qos:mandatory sendrecv Now A performs resource reservation, let's say using RSVP. Sends PATH and receives RESV. Now the preconditions are met, so A can send a COMET. what should A write in the SDP of the COMET message? a=qos:success sendrecv this would indicate that the resources are ready, and that the media stream was sendrecv. or a=qos:success send Because the resources are ready to send. B will take care of the QoS in the other direction. Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 10:33:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24769 for ; Wed, 12 Jul 2000 10:33:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06D9C44417; Wed, 12 Jul 2000 10:33:44 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail1.rdc2.pa.home.com (mail1.rdc2.pa.home.com [24.12.106.240]) by lists.bell-labs.com (Postfix) with ESMTP id 9910644345; Wed, 12 Jul 2000 10:33:39 -0400 (EDT) Received: from home.com ([24.3.205.203]) by mail1.rdc2.pa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000712143338.SDIA1147.mail1.rdc2.pa.home.com@home.com>; Wed, 12 Jul 2000 07:33:38 -0700 Message-ID: <396C81B4.60B45DC0@home.com> Date: Wed, 12 Jul 2000 10:33:24 -0400 From: Herman Silbiger Reply-To: hsilbiger@ieee.org X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Alec Brusilovsky Cc: sip@lists.bell-labs.com, Lawrence Conroy , pint@lists.research.bell-labs.com, SPIRITS list References: <39414575.C030AC3C@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: [PINT] UDP support changed from SHOULD to MUST Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Annex D to Rec. T.38 specifies SIP/SDP as an optional call establishment metho, T.38. being the Group 3 fax over IP protocol. Support for UDP is mandatory (MUST) in T.38, so it is therefore logically a requirement for SDP. Herman Alec Brusilovsky wrote: > Please see my comments inline. > > Regards, > Alec > > Lawrence Conroy wrote: > > > * UDP support changed from SHOULD to MUST in SIP 2453 bis draft. > > It looks like support for UDP is gradually moving from a SHOULD to a > > MUST in SIP. > > > > In PINT we may not have that assumption. We can have a good reason > > for using TCP only (inline content, security using TLS, ...), so *for > > PINT* I'd prefer to leave this as a SHOULD. > > > > I would like to add to what Lawrence is saying that some SIP applications > might need a more flexible and rapid session set up than others. PINT is a > good example, SPIRITS might as well be another one, assuming that the WG > will decide to use SIP. > > > > > I wonder if the move to a MUST in the core spec will cause grief for > > any other extension or application. > > > > The key point here is ->in the core spec<- > > Looks like the core spec. needs to be more accommodating to the needs of > extensions (PINT). SHOULD is just fine. Why break something that actually > works? > > > > > > > I had the same feeling at the Interim meeting in D.C. when the > > subject of "Busy Line Verification" was raised - there's a lot of > > focus on VoIP, when I can easily imagine SIP being used for a much > > wider set of applications even for "straight" conferences; for > > example, Quake, as Dean suggests. > > Let's imagine an Operator listening in on the sampled Quake audio > > track that I'm conferencing. How long before the Police arrive? An > > over-emphasis on VoIP can lead to bad assumptions, IMHO - SIP is much > > wider than that. > > -- > > lwc@roke.co.uk -- +44 1794 833666 > > ------------------------------------------------------------- > > Herewith a pointless waste of a few lines, stating that > > Roke Manor Research Limited is NOT responsible for my rantings > > and that they would very much like people to sue me rather than > > them if this email contains racist or sexist comments, please. > > Also, I can't do anything; only our lawyers can, so speak to them. > > Oh, and by the way, if our I.T. department has so mangled our > > email system that this has been misdirected, beware that having > > read this far, your eyes are about to fall out from reading > > this highly sensitive information, unless you immediately > > forget that this ever darkened your mailbox. Do it now. > > ------------------------------------------------------------- > > > > _______________________________________________ > > PINT mailing list > > PINT@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/pint _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 10:53:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25713 for ; Wed, 12 Jul 2000 10:53:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F17DD44455; Wed, 12 Jul 2000 10:52:57 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by lists.bell-labs.com (Postfix) with ESMTP id 8F75D44452 for ; Wed, 12 Jul 2000 10:52:54 -0400 (EDT) Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id KAA02872; Wed, 12 Jul 2000 10:52:38 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Jeff Mark'" , , "'Kevin Davis'" , Subject: RE: [SIP] DTMF and voice-over-packet Date: Wed, 12 Jul 2000 10:52:37 -0400 Message-ID: <009401bfec10$d28dbf40$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Jeff, Actually, I did test drive the United site this morning, and found that while it could pleasantly do the job without using DTMF, it is quite taxing to say "yes" or "no" repeatedly. At one step - I deliberately answered wrongly, and the system did give me an option of pressing "1" or saying "yes" or say "repeat a question". Two DTMF applications that touch our lives every day are telephone banking and voice message retrievals. Even if I could dial and say give me balance of account number "two four five six" or "play the fifth message from the top", I doubt that I can use a system without DTMF based keying for long. Voice recognition hasn't done away the need of typing on computers. I do have voice recognition software from L & H on my PC, but after initial testing and experimentation a few years ago I stopped using it, as I prefer to type than talk to my computer. As a former architect of messaging switches that support millions of subscribers and their mail boxes, I can say confidently that for some applications, DTMF will be preferable even though voice recognition may equally (or let us accept even better) do the job. And, what about people who suffer from vocal tract defects or temporary loss of voice or need to support multiple language user interface? The DTMF keying provides the easiest escape route. Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jeff Mark > Sent: Tuesday, July 11, 2000 6:57 PM > To: ldang@vovida.com; bkumar@ennovatenetworks.com; 'Kevin Davis'; > sip@lists.bell-labs.com > Subject: RE: [SIP] DTMF and voice-over-packet > > > Check out United Airlines automated flight info line for an example > application that does not use DTMF. Take a test drive by calling > 1-800-824-6200. > > -Jeff > Dialogic, an Intel Company > > > From: Luan Dang [mailto:ldang@vovida.com] > > > > Brijesh Kumar wrotes: > > > Hi Kevin, > > > > > > You are right. > > > > > > Whenever, I dial into systems that give me choice of > saying "one" or > > > pressing "1", guess what I do - I almost always press > "1". I believe > > > that most people like to press "4""5""3""7" than say > "four five three > > > seven", and would continue to do the same for years to > come. It is not > > > just security - it is security plus convenience. I guess that DTMF > > > will be used even in year 2020. > > > > > > Cheers, > > > > > > --brijesh > > > Ennovate Networks Inc. > > > > > Brijesh, > > > > You are missing the bigger picture. In the future you will not have > > to say "one", "two"..., you can simply ask for what you > want. This is > > the by product of current DTMF design. > > On security, there are many different methods including speech > > authentication and time sensitive pin code that would not matter if > > someone over heard you. > > I sure hope we will not be using DTMF in year 2020. > > > > -- > > Luan Dang > > Senior VP & CTO mailto:ldang@vovida.com > > Vovida Networks, Inc. voice:(408)383-1060 > > http://www.vovida.com fax:(408)383-1062 > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 12 11:05:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26341 for ; Wed, 12 Jul 2000 11:05:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B85D244458; Wed, 12 Jul 2000 11:05:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id EB98F44345 for ; Wed, 12 Jul 2000 11:05:12 -0400 (EDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA18610; Wed, 12 Jul 2000 08:05:12 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11955; Wed, 12 Jul 2000 08:05:04 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14700.35104.160239.413723@thomasm-u1.cisco.com> Date: Wed, 12 Jul 2000 08:05:04 -0700 (PDT) To: Cc: "'Jeff Mark'" , , "'Kevin Davis'" , Subject: RE: [SIP] DTMF and voice-over-packet In-Reply-To: <009401bfec10$d28dbf40$d001010a@tst.ennovatenetworks.com> References: <009401bfec10$d28dbf40$d001010a@tst.ennovatenetworks.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Brijesh Kumar writes: > Actually, I did test drive the United site this morning, and found > that while it could pleasantly do the job without using DTMF, it is > quite taxing to say "yes" or "no" repeatedly. At one step - I > deliberately answered wrongly, and the system did give me an option of > pressing "1" or saying "yes" or say "repeat a question". I hope that the Brave New World that Christian has in mind uses a natural language processors with loads of fuzzy logic rather than faithfully reproducing an IVR maze with speech! > I can say confidently > that for some applications, DTMF will be preferable even though voice > recognition may equally (or let us accept even better) do the job. This SHOULD be a false dilemma: the same thing happened with GUI's until regular users decided they like keyboard shortcuts. Of course, most GUI based programs are not as, shall we say, rich as their text counterparts in the rush to dumb them down for the unwashed masses. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 11:41:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28314 for ; Wed, 12 Jul 2000 11:41:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB41744452; Wed, 12 Jul 2000 11:40:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id E8DFF443B7 for ; Wed, 12 Jul 2000 11:40:13 -0400 (EDT) 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 KAA10348 for ; Wed, 12 Jul 2000 10:40:12 -0500 (CDT) 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 KAA23497 for ; Wed, 12 Jul 2000 10:40:12 -0500 (CDT) Received: from eamrcnt740.exu.ericsson.se ([138.85.133.41]) by 138.85.133.38 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 12 Jul 2000 15:39:26 0000 (GMT) Received: by eamrcnt740.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id <3LGK2QZC>; Wed, 12 Jul 2000 10:39:40 -0500 Message-ID: <9D648155F1FCD3119D5400508B090503B51F8C@eamrcnt732.exu.ericsson.se> From: "Mark Peck (EUS)" To: "'Anatoli Levine'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] DTMF and voice-over-packet Date: Wed, 12 Jul 2000 10:37:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com If users are still sending alphanumeric data using DTMF in 2020 then we all (communications industry) ought to admit that we failed and shoot ourselves. Jonathan and Christian have it right on this one. MWP -- Mark W. Peck Ericsson Inc. Mark.Peck@ericsson.com > -----Original Message----- > From: Anatoli Levine [mailto:alevine@radvision.com] > Sent: Tuesday, July 11, 2000 6:08 PM > To: Jeff Mark > Cc: ldang@vovida.com; bkumar@ennovatenetworks.com; 'Kevin Davis'; > sip@lists.bell-labs.com > Subject: Re: [SIP] DTMF and voice-over-packet > > > Jeff, > > well, the this was rather an example of a bad interface - you > can still use > DTMF to get the flight info, but in some cases only after the > system fails > with the voice response... We are talking convenience here, > so even in 2020 we > will have some things which will be easier and faster to type > (DTMF) than to > say... > > Anatoli > > Jeff Mark wrote: > > > Check out United Airlines automated flight info line for an example > > application that does not use DTMF. Take a test drive by calling > > 1-800-824-6200. > > > > -Jeff > > Dialogic, an Intel Company > > > > From: Luan Dang [mailto:ldang@vovida.com] > > > > > > Brijesh Kumar wrotes: > > > > Hi Kevin, > > > > > > > > You are right. > > > > > > > > Whenever, I dial into systems that give me choice of > saying "one" or > > > > pressing "1", guess what I do - I almost always press > "1". I believe > > > > that most people like to press "4""5""3""7" than say > "four five three > > > > seven", and would continue to do the same for years to > come. It is not > > > > just security - it is security plus convenience. I > guess that DTMF > > > > will be used even in year 2020. > > > > > > > > Cheers, > > > > > > > > --brijesh > > > > Ennovate Networks Inc. > > > > > > > Brijesh, > > > > > > You are missing the bigger picture. In the future you > will not have > > > to say "one", "two"..., you can simply ask for what you > want. This is > > > the by product of current DTMF design. > > > On security, there are many different methods including speech > > > authentication and time sensitive pin code that would not > matter if > > > someone over heard you. > > > I sure hope we will not be using DTMF in year 2020. > > > > > > -- > > > Luan Dang > > > Senior VP & CTO mailto:ldang@vovida.com > > > Vovida Networks, Inc. voice:(408)383-1060 > > > http://www.vovida.com fax:(408)383-1062 > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/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 Jul 12 12:07:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29903 for ; Wed, 12 Jul 2000 12:07:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1495E443D2; Wed, 12 Jul 2000 12:05:58 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 0C5DA4434D for ; Wed, 12 Jul 2000 12:05:53 -0400 (EDT) Received: (qmail 24004 invoked by uid 1002); 12 Jul 2000 16:04:03 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 12 Jul 2000 19:04:02 +0300 (IDT) To: SIP X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14700.38471.657903.79397@jodie.lucid> Subject: [SIP] Contact in Methods Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit When will a Contact header field be used when sent in Methods? If I receive an INVITE with a Contact, what should I do with it? Is it used only if I initiate a new call leg? Thanks for the help. -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 12:32:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01178 for ; Wed, 12 Jul 2000 12:32:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C5684437E; Wed, 12 Jul 2000 12:32:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id A56EC4434D for ; Wed, 12 Jul 2000 12:32:25 -0400 (EDT) Received: from raymond ([216.181.56.35]) by broadsoft.com (8.8.8) id MAA29412; Wed, 12 Jul 2000 12:32:23 -0400 (EDT) From: "Doug Sauder" To: Date: Wed, 12 Jul 2000 12:34:14 -0400 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] Is SDP sufficient? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I have been thinking through some issues associated with RTP streams and security in the context of two party calls. The main issue is, How can the RTP receiver filter the incoming RTP packets in a way that guarantees -- or at least provides reasonable assurance -- that those packets come from the other party to the call? The SDP that comes as part of a SIP message tells the IP address and UDP port of a receiver, but not of a sender. What I think is worth considering as a solution would be for the two parties in the call to communicate their source IDs (the SSRC in RTP), since that is probably the best way to filter incoming RTP packets. Perhaps this could be done with an attribute in the SDP. Alternatively, the sending host address and port could identify a sender, but that would not allow for media hand-offs to another host. I know a complete solution for security could not be accomplished without use of authentication and encryption. But, even at a philosophical level, I have a hard time with the way calls are set up -- namely, the fact that the two parties to a call exchange information about their receiving ports, but do not exchange any information to identify the streams they are sending. Doug Sauder Broadsoft, Inc _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 13:13:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02958 for ; Wed, 12 Jul 2000 13:13:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 467C1443FE; Wed, 12 Jul 2000 13:13:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 4F894443CA for ; Wed, 12 Jul 2000 13:13:12 -0400 (EDT) Received: from cs.columbia.edu (dhcp1.cs.columbia.edu [128.59.19.201]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA15360; Wed, 12 Jul 2000 13:12:42 -0400 (EDT) Message-ID: <39687857.4732F4F3@cs.columbia.edu> Date: Sun, 09 Jul 2000 09:04:23 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Brett Tate , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> <39663D1D.B73DB10A@dynamicsoft.com> <396722BB.26C1BF39@cs.columbia.edu> <06ca01bfe946$7f47fcf0$3102a8c0@broadsoft.com> <3967F621.973F3304@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Its a general problem associated with correlating multiple SDPs > associated with the same session. This can happen even in SAP. Lets say > a SAP announcement is sent, containing SDP 1 with two audio and a video > stream. Later on, an updated SDP (SDP 2) is sent out. This SDP has one > audio and one video stream. Now, if my media tools started off based on > SDP 1, and now SDP 2 comes, which audio stream should be removed? This > is the same problem we have in SIPs usage of SDP. Aligning media streams > between SDP allows us to determine this correlation. No, that's not my understanding of SDP usage in SAP. In SAP, each o= version is completely independent and has no relationship to the previous one. In other words, logically, you end up tearing down all the old media streams and listening/sending to new ones. A smart implementation could keep a list of the old sessions and compare m= lines for port and address, and keep those sessions/tools where nothing has changed. None of the first-generation Mbone tools (and I doubt many of the current ones) have the ability to change port or multicast address without restarting the tool, so starting afresh is pretty much the only thing you can do in any event even for media property changes. > > The alignment of media streams via positioning works just fine. Is it > elegant - no. But, it works, and its already there. If there is an > actual bug or unaddressed issue, then we can resolve it. But, I don't > want to change SDP usage in SIP just because its not elegant. We really > have to worry about backwards compatibility. Let me repeat this, since it seems to get confused: There are two wholly separate issues: Q1) What SDP should an implementation *send* if it wants to delete an existing media stream or doesn't want to listen to a particular session offered in an INVITE? A: Same SDP, with port 0 for the media session not (no longer) wanted. Q2) What should happen if somebody *receives* SDP that differs in order or number of m= lines? A: Two possibilities. A1: Given that this makes simple implementations easier (don't have to keep around all the irrelevant video, wb, chat, etc. lines) and simply return a fixed SDP (m=audio something-or-other), it is probably a good idea for the initiator to recognize this and set up the audio stream, say, accordingly and not send data for the others nor start up the respective tools. This doesn't work for multiple media streams of the same kind, but works ok for the common case. A2: Be a stickler and reject the SDP (and explain to customer why your implementation won't accept phone calls...) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 13:15:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03081 for ; Wed, 12 Jul 2000 13:15:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 33A124442A; Wed, 12 Jul 2000 13:13:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C3EDE443D2 for ; Wed, 12 Jul 2000 13:13:14 -0400 (EDT) Received: from cs.columbia.edu (dhcp1.cs.columbia.edu [128.59.19.201]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA15357; Wed, 12 Jul 2000 13:12:41 -0400 (EDT) Message-ID: <396874B4.AD7C9979@cs.columbia.edu> Date: Sun, 09 Jul 2000 08:48:52 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Brett Tate , SIPbell-labs Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis References: <037501bfe76d$14d07300$3102a8c0@broadsoft.com> <39652839.A8CA501F@dynamicsoft.com> <39660E1A.7F16F52C@cs.columbia.edu> <39661DAF.34044F4E@dynamicsoft.com> <05fa01bfe84d$3944a8b0$3102a8c0@broadsoft.com> <39663D1D.B73DB10A@dynamicsoft.com> <396722BB.26C1BF39@cs.columbia.edu> <39680150.3981E4E4@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > Henning Schulzrinne wrote: > > > > My recollection > > is that it was difficult to impossible to find somebody that could test > > a second media (video) with us, let alone two instances of a media type. > > Siphone certainly does both. I vaguely remember actually testing this > feature with someone at the second bakeoff. In general, setting ports of > rejected media streams to 0 is rather trivial by any coding standards > and I can't see any reasons for not doing that (except people not being > aware that's necessary). > I'm not arguing against that, just for greater precision on the "liberal what you accept side". _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 13:32:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03873 for ; Wed, 12 Jul 2000 13:32:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E4A014443C; Wed, 12 Jul 2000 13:31:30 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 2E2684435E for ; Wed, 12 Jul 2000 13:31:27 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TLPNR>; Wed, 12 Jul 2000 10:31:21 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8A9F@sd_exchange.nuera.com> From: "Fox, Mike" To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: Tunneling with SIP Date: Wed, 12 Jul 2000 10:31:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Perhaps it would be more suitable to initiate a SOAP conversation or session using SIP/SDP? Mike > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 11, 2000 8:50 PM > To: Fox, Mike > Cc: sip@lists.bell-labs.com > Subject: [SIP] Re: Tunneling with SIP > > > > > "Fox, Mike" wrote: > > > > Jonathan Rosenberg wrote: > > > I would not advocate tunneling DHCP over SIP, HTTP over SIP, > > > or SLP over > > > SIP, since those protocols > > > don't do the same thing SIP does. Same with megaco/mgcp. > > > Tunneling them > > > over SIP serves no purpose. SIP is not a good transfer > > > protocol (see the > > > Guidelines for Authors of SIP Extensions: > > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-gui > > >delines-00.txt). > > >Just use the native transport define by the protocol. > > > > Perhaps it would be too simple an extrapolation to conclude > that you are not > > in favor of ... > > http://www.ietf.org/internet-drafts/draft-deason-sip-soap-00.txt > > > > Could you share your opinion? (I would mine, but few care > about it! ;-) > > I do not believe that SIP is a useful RPC mechanism. None of its user > discovery and registration capabilities are needed for RPC, neither > are most of its proxy functions. As it is not an ideal transfer > protocol, it is not good at carrying serialized objects of any large > size. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 14:22:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07082 for ; Wed, 12 Jul 2000 14:22:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D2A3C4435E; Wed, 12 Jul 2000 14:22:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 7E24E44336 for ; Wed, 12 Jul 2000 14:22:19 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TLP34>; Wed, 12 Jul 2000 11:22:14 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8AAA@sd_exchange.nuera.com> From: "Fox, Mike" To: James Undery , Jonathan Rosenberg Cc: sip@lists.bell-labs.com Date: Wed, 12 Jul 2000 11:22:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Tunneling with SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com 'A la SIP static images, is a URL like: Soap-Server: enough for a SOAP enabled SIP element to find a SOAP server? What happens next is another problem (one of product differentiation rather than SIP specification). If you like, or need security, use HTTPS and/or other security inside SOAP. Best regards, Mike Fox > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Wednesday, July 12, 2000 1:01 AM > To: Jonathan Rosenberg > Cc: Fox, Mike; sip@lists.bell-labs.com > Subject: Re: [SIP] Re: Tunneling with SIP > > > > > Jonathan Rosenberg wrote: > > > "Fox, Mike" wrote: > > > > > > Jonathan Rosenberg wrote: > > > > I would not advocate tunneling DHCP over SIP, HTTP over SIP, > > > > or SLP over > > > > SIP, since those protocols > > > > don't do the same thing SIP does. Same with megaco/mgcp. > > > > Tunneling them > > > > over SIP serves no purpose. SIP is not a good transfer > > > > protocol (see the > > > > Guidelines for Authors of SIP Extensions: > > > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-gui > > > >delines-00.txt). > > > >Just use the native transport define by the protocol. > > > > > > Perhaps it would be too simple an extrapolation to > conclude that you are not > > > in favor of ... > > > http://www.ietf.org/internet-drafts/draft-deason-sip-soap-00.txt > > > > > > Could you share your opinion? (I would mine, but few care > about it! ;-) > > I doubt many want mine, but, I'll give it anyway ;^) > > > > > I do not believe that SIP is a useful RPC mechanism. None > of its user > > discovery and registration capabilities are needed for RPC, neither > > are most of its proxy functions. As it is not an ideal transfer > > protocol, it is not good at carrying serialized objects of any large > > size. > > There are times however when a RPC may need to be performed > in relation to a > session and proxies may be interested in the result. I can't > believe anyone > interested in ushering in the next generation of services > couldn't see this. That > said as a generic RPC transport mechanism SIP is a very poor > choice, and from a > security point SOAP is a nightmare (any RPC mechanism > designed to breech firewalls > without a ALG is a nightmare.) > > James Undery > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 14:52:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08608 for ; Wed, 12 Jul 2000 14:52:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E9737443BA; Wed, 12 Jul 2000 14:52:05 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id AB0D344370 for ; Wed, 12 Jul 2000 14:52:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 12 14:50:09 EDT 2000 Received: by lists.bell-labs.com (Postfix) id B1EE144358; Wed, 12 Jul 2000 14:36:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 6B45844347 for ; Wed, 12 Jul 2000 14:36:59 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA15812; Wed, 12 Jul 2000 13:36:55 -0500 Cc: SIP Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA15804; Wed, 12 Jul 2000 13:36:54 -0500 Message-ID: <396CBAC0.527BA41B@lucent.com> Date: Wed, 12 Jul 2000 13:36:48 -0500 From: "Vijay K. Gurbani" Reply-To: vkg@lucent.com Organization: Intelligent Network Unit X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Original-CC: SIP Subject: Re: [SIP] Contact in Methods References: <14700.38471.657903.79397@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir Oren wrote: > > When will a Contact header field be used when sent in Methods? If I > receive an INVITE with a Contact, what should I do with it? Save it. The caller is telling you that it can be directly reached at that address for subsequent transactions (such as a BYE). If you decide to accept the INVITE, you may include a Contact header in the 200 OK which may be used by the caller to send the ACK directly to you. Having said that, attention needs to be paid to Route and Record-Route headers as well. If a proxy inserted a Record-Route header in a request, you cannot bypass it completely by sending subsequent requests directly to the Contact address. The RFC outlines how to construct Route headers from Record-Route and Contact headers to route subsequent requests. See sections 6.33, 6.37 for that. For an overview of Contact and its usage in requests and responses, see sections 6.13 and section 11. These sections pertain to the June 9th 2000 bis draft. I think the FAQ also has some information on Contact headers and routing. Regards, - vijay -- Vijay K. Gurbani vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org IN Architecture and Internet Software Group Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418 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 Jul 12 15:37:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10629 for ; Wed, 12 Jul 2000 15:37:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1FF7F443D2; Wed, 12 Jul 2000 15:35:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by lists.bell-labs.com (Postfix) with ESMTP id 812C64435E for ; Wed, 12 Jul 2000 15:35:37 -0400 (EDT) Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id PAA17915; Wed, 12 Jul 2000 15:36:02 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA01276; Thu, 13 Jul 2000 00:35:36 +0500 Message-Id: <200007121935.AAA01276@hafez.east.isi.edu> To: Doug Sauder Cc: sip Subject: Re: [SIP] Is SDP sufficient? In-Reply-To: Your message of "Wed, 12 Jul 2000 12:34:14 EDT." Date: Wed, 12 Jul 2000 15:35:35 -0400 From: Colin Perkins Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --> Doug Sauder writes: > >I have been thinking through some issues associated with RTP streams and >security in the context of two party calls. The main issue is, How can the >RTP receiver filter the incoming RTP packets in a way that guarantees -- or >at least provides reasonable assurance -- that those packets come from the >other party to the call? The SDP that comes as part of a SIP message tells >the IP address and UDP port of a receiver, but not of a sender. > >What I think is worth considering as a solution would be for the two parties >in the call to communicate their source IDs (the SSRC in RTP), since that is >probably the best way to filter incoming RTP packets. Perhaps this could be >done with an attribute in the SDP. Alternatively, the sending host address >and port could identify a sender, but that would not allow for media >hand-offs to another host. Note that the RTP SSRC of a participant may change if the session is a multicast one (due to SSRC collision detection and avoidance). Colin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 15:58:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11401 for ; Wed, 12 Jul 2000 15:58:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4CC12443FA; Wed, 12 Jul 2000 15:57:42 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 59CA5443EE for ; Wed, 12 Jul 2000 15:57:21 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA10922; Wed, 12 Jul 2000 21:57:14 +0200 (MET DST) Message-ID: <396CCDA5.34C9299D@fokus.gmd.de> Date: Wed, 12 Jul 2000 21:57:25 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Sauder Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Is SDP sufficient? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Doug Sauder wrote: > > I have been thinking through some issues associated with RTP streams and > security in the context of two party calls. The main issue is, How can the > RTP receiver filter the incoming RTP packets in a way that guarantees -- or > at least provides reasonable assurance -- that those packets come from the > other party to the call? The SDP that comes as part of a SIP message tells > the IP address and UDP port of a receiver, but not of a sender. > > What I think is worth considering as a solution would be for the two parties > in the call to communicate their source IDs (the SSRC in RTP), since that is > probably the best way to filter incoming RTP packets. Perhaps this could be > done with an attribute in the SDP. Alternatively, the sending host address > and port could identify a sender, but that would not allow for media > hand-offs to another host. There is a new I-D on conveying source information in SDP: draft-ietf-mmusic-sdp-srcfilter-00.txt. Media hand-offs have to be solved at application layer by sending appropriate INVITEs. Jiri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 16:18:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12244 for ; Wed, 12 Jul 2000 16:18:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7D3A4441B; Wed, 12 Jul 2000 16:18:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lists.bell-labs.com (Postfix) with SMTP id B9CBD443F0 for ; Wed, 12 Jul 2000 16:18:29 -0400 (EDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Jul 2000 13:17:26 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Wed, 12 Jul 2000 13:17:25 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C3180@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Colin Perkins'" , Doug Sauder Cc: sip Subject: RE: [SIP] Is SDP sufficient? (to identify RTP sources) Date: Wed, 12 Jul 2000 13:17:13 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > --> Doug Sauder writes: > > > >I have been thinking through some issues associated with RTP > streams and > >security in the context of two party calls. The main issue > is, How can the > >RTP receiver filter the incoming RTP packets in a way that > guarantees -- or > >at least provides reasonable assurance -- that those packets > come from the > >other party to the call? The SDP that comes as part of a > SIP message tells > >the IP address and UDP port of a receiver, but not of a sender. The short answer is, if you want security, use encryption. Send the key, or a pointer on how to build the key, in the original SDP. Messages that are encrypted with that key come from an authorized source; other messages may be forged. Checking the IP source address is always a questionable idea. It does not bring you real security, since addresses can be spoofed, and it creates lots of operational problems with multi-homed hosts and mobile hosts. In addition, you will observe that any attempt to check the IP source creates a race condition between the arrival of the RTP packets and the completion of the initial SIP transaction. Christian Huitema _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Jul 12 20:49:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19202 for ; Wed, 12 Jul 2000 20:49:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6ADB14435C; Wed, 12 Jul 2000 20:49:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail1.qualcomm.com (mail1.qualcomm.com [129.46.2.6]) by lists.bell-labs.com (Postfix) with ESMTP id 58BE044341 for ; Wed, 12 Jul 2000 20:49:23 -0400 (EDT) Received: from harleeng.qualcomm.com (harleeng.qualcomm.com [129.46.172.108]) by mail1.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id RAA11635 for ; Wed, 12 Jul 2000 17:49:21 -0700 (PDT) Message-Id: <4.3.1.0.20000712174913.00bdc470@jittlov.qualcomm.com> X-Sender: harleeng@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 12 Jul 2000 17:49:19 -0700 To: sip@lists.bell-labs.com From: Harleen Gill Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] Informing end clients of a session teardown and need to rejoin. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com What is an acceptable way in accordance to the standard to notify an end terminal that only implements a user agent client (not a user agent server) that their session/call is about to be terminated and that they need to re-register at a new particular address? In this case the client cannot receive the BYE message and based on the standard sending a 300 series message after a session is established is not acceptable. In general, a mechanism is needed to asynchronously inform clients that the session they are currently participating in is about to be terminated and that they need to immediately rejoin at a new address. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 01:04:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25464 for ; Thu, 13 Jul 2000 01:04:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F26544373; Thu, 13 Jul 2000 01:04:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 74AEF44341 for ; Thu, 13 Jul 2000 01:04:17 -0400 (EDT) Received: (from shbhatna@localhost) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id BAA00493 for sip@lists.bell-labs.com; Thu, 13 Jul 2000 01:04:01 -0400 (EDT) From: Shail Bhatnagar Message-Id: <200007130504.BAA00493@bounty.cisco.com> To: sip@lists.bell-labs.com Date: Thu, 13 Jul 2000 01:04:01 -0400 (EDT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] about Contact in REGISTER ... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This may be an implementation issue but I would like to elicit opinion/ comments about the applicability/correctness of the following REGISTER. REGISTER sip:domain.com To: sip:user@domain.com Contact: Should a registrar accept such registrations (host portion of Contact SIP URL is the fqdn of the proxy let us assume) ?? I think the possible intent of the user is that he is reachable on the PSTN network through this phone number - 9195551212. If the proxy accepts such registrations - it should probably ensure that it has a route/gateway which can terminate calls to 9195551212. Comments ?? Thanks, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 01:16:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27045 for ; Thu, 13 Jul 2000 01:16:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 54B00443BD; Thu, 13 Jul 2000 01:15:36 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 531F944390 for ; Thu, 13 Jul 2000 01:15:32 -0400 (EDT) Received: from dynamicsoft.com (1Cust57.tnt2.freehold.nj.da.uu.net [63.17.114.57]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA19444; Thu, 13 Jul 2000 01:17:00 -0400 (EDT) Message-ID: <396D512E.5798D1F8@dynamicsoft.com> Date: Thu, 13 Jul 2000 01:18:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.bell-labs.com Subject: Re: [SIP] about Contact in REGISTER ... References: <200007130504.BAA00493@bounty.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This is perfectly fine. Its useful for when you want to run a system that separates users, phone numbers, and phones. So, for each user, you have a mapping to a number, and then a number to a phone. Such a thing has been discussed on the list, in fact. Note that to properly support this, your proxy better support the new loop detection mechanisms, which ensure that "spiraled" requests are not detected as loops. -Jonathan R. Shail Bhatnagar wrote: > > This may be an implementation issue but I would like to elicit opinion/ > comments about the applicability/correctness of the following REGISTER. > > REGISTER sip:domain.com > To: sip:user@domain.com > Contact: > > Should a registrar accept such registrations (host portion of Contact > SIP URL is the fqdn of the proxy let us assume) ?? > > I think the possible intent of the user is that he is reachable on the PSTN > network through this phone number - 9195551212. > > If the proxy accepts such registrations - it should probably ensure that it > has a route/gateway which can terminate calls to 9195551212. > > Comments ?? > > Thanks, > Shail > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 01:18:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27377 for ; Thu, 13 Jul 2000 01:18:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB0CB443DD; Thu, 13 Jul 2000 01:18:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 26C92443BA for ; Thu, 13 Jul 2000 01:18:01 -0400 (EDT) Received: from dynamicsoft.com (1Cust57.tnt2.freehold.nj.da.uu.net [63.17.114.57]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA19452; Thu, 13 Jul 2000 01:19:26 -0400 (EDT) Message-ID: <396D51BF.84A4A5A2@dynamicsoft.com> Date: Thu, 13 Jul 2000 01:21:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harleen Gill Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Informing end clients of a session teardown and need to rejoin. References: <4.3.1.0.20000712174913.00bdc470@jittlov.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Harleen Gill wrote: > > What is an acceptable way in accordance to the standard to notify an end > terminal that only implements a user agent client (not a user agent server) > that their session/call is about to be terminated and that they need to > re-register at a new particular address? > In this case the client cannot receive the BYE message and based on the > standard sending a 300 series message after a session is established is not > acceptable. Its hard to give an answer since you have not given any details on why this is needed. Normally, the device itself is the entity that knows it needs to re-register. If someone else knows a client needs to re-register, it could simply perform that registration for it, as a third party registration. I'm also not clear on why the device would be a UAC only. > > In general, a mechanism is needed to asynchronously inform clients that the > session they are currently participating in is about to be terminated and > that they need to immediately rejoin at a new address. Can you please motivate that? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 02:07:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08567 for ; Thu, 13 Jul 2000 02:07:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AEF6C44341; Thu, 13 Jul 2000 02:06:49 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6FE4844338 for ; Thu, 13 Jul 2000 02:06:46 -0400 (EDT) Received: from dynamicsoft.com (1Cust57.tnt2.freehold.nj.da.uu.net [63.17.114.57]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA19629; Thu, 13 Jul 2000 02:07:56 -0400 (EDT) Message-ID: <396D5D1D.958D4C85@dynamicsoft.com> Date: Thu, 13 Jul 2000 02:09:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rafi Cc: sip@lists.bell-labs.com Subject: Re: [SIP] How to detect interworking ? References: <022801bfec07$4fd2bb40$8c40000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit By its nature such an interworking box appears as a perfectly legitimate SIP UA. So, from a pure protocol perspective, no. However, I have been updating the caller preferences spec. One of things I added is that you can use the new Contact parameters in the Contact in INVITE and 200 OK to convey useful info about who/what was contacted. One of the things that you can include is a textual description, so: 200 OK Contact: sip:iwf@columbia.edu;description="interworking with H.323" This is not useful for automated processing, but could allow the user to know. -Jonathan R. > rafi wrote: > > Hi, > > Is it not useful for a UAC to know whenever > there is an interworking taking place (For e.g. > SIP-H323)? Is it possible for a "gateway" to > indicate such information to UAC? > > Thank you > Rafi Assadi H.M -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 05:04:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10402 for ; Thu, 13 Jul 2000 05:04:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D09744342; Thu, 13 Jul 2000 05:04:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by lists.bell-labs.com (Postfix) with ESMTP id AA8D744336 for ; Thu, 13 Jul 2000 05:03:59 -0400 (EDT) Received: from ray ([63.198.80.207]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXM00BU1P57W1@mta5.snfc21.pbi.net> for sip@lists.bell-labs.com; Thu, 13 Jul 2000 02:03:09 -0700 (PDT) Date: Wed, 12 Jul 2000 14:03:41 -0700 From: Ray Tayek X-Sender: rtayek@netcom.netcom.com To: sip@lists.bell-labs.com Message-id: <4.2.0.58.20000712135628.00c06b10@netcom.netcom.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Content-type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] open source for sip? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com hi, i am developing an app that needs to support voip from one machine to another (no phone system involved) (but possibly 3 party conversation). we will have a quicknet internet phone jack card. i have used the open323 stuff to have a 2 way phone conversation, but h323 seems like gross overkill and h323 will have lots of problems getting through firewalls. i was hoping for something a bit simpler (maybe just some rtp stuff restricted to a few ports?) is there open source project for sip out there? any pointers would be appreciated. thanks --- ray http://home.pacbell.net/rtayek/ vice chair orange county java users group http://www.ocjug.org/ hate spam? http://samspade.org/ssw/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 06: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 ESMTP id GAA11556 for ; Thu, 13 Jul 2000 06:30:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4366F44357; Thu, 13 Jul 2000 06:29:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 613FC44336 for ; Thu, 13 Jul 2000 06:29:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11470; Thu, 13 Jul 2000 06:29:26 -0400 (EDT) Message-Id: <200007131029.GAA11470@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Thu, 13 Jul 2000 06:29:26 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-guidelines-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Guidelines for Authors of SIP Extensions Author(s) : J. Rosenberg, H.Schulzrinne Filename : draft-ietf-sip-guidelines-00.txt Pages : 15 Date : 12-Jul-00 The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-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-guidelines-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-guidelines-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: <20000712140812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-guidelines-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-guidelines-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140812.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 Jul 13 06:59:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12099 for ; Thu, 13 Jul 2000 06:59:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B27B44342; Thu, 13 Jul 2000 06:59:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id C093B44336 for ; Thu, 13 Jul 2000 06:59:18 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA17796; Thu, 13 Jul 2000 11:57:23 +0100 (BST) Message-ID: <396DA092.D918A860@ubiquity.net> Date: Thu, 13 Jul 2000 11:57:22 +0100 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: Jonathan Rosenberg Cc: "Fox, Mike" , sip@lists.bell-labs.com Subject: Re: [SIP] Re: Tunneling with SIP References: <613A6A6A3F09D3118F5C00508B2C24FEAD8A85@sd_exchange.nuera.com> <396BEAD4.CDEA202E@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > "Fox, Mike" wrote: > > > > Jonathan Rosenberg wrote: > > > I would not advocate tunneling DHCP over SIP, HTTP over SIP, > > > or SLP over > > > SIP, since those protocols > > > don't do the same thing SIP does. Same with megaco/mgcp. > > > Tunneling them > > > over SIP serves no purpose. SIP is not a good transfer > > > protocol (see the > > > Guidelines for Authors of SIP Extensions: > > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-gui > > >delines-00.txt). > > >Just use the native transport define by the protocol. > > > > Perhaps it would be too simple an extrapolation to conclude that you are not > > in favor of ... > > http://www.ietf.org/internet-drafts/draft-deason-sip-soap-00.txt > > > > Could you share your opinion? (I would mine, but few care about it! ;-) Well I would. The reason I submitted this draft was to encourage thought about the relationship of SIP and XML for services. Not because I think SIP and SOAP necessarily provides the absolute ultimate answer. > I do not believe that SIP is a useful RPC mechanism. None of its user > discovery and registration capabilities are needed for RPC, neither > are most of its proxy functions. As it is not an ideal transfer > protocol, it is not good at carrying serialized objects of any large > size. In the draft you can see I explicitly said that SIP does not provide the basis for a high efficiency or general computing RPC mechanism. I note that you have now copied this sentiment into your extensions guidelines draft ;) I also wouldn't expect that size limits on datagram packets would be much of an issue for SOAP messages. What SIP/SOAP might do is provide a clean interface for sophisticated service requests between the many different forms of SIP enabled nodes we all expect to see in the near future. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 07:18:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13050 for ; Thu, 13 Jul 2000 07:18:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB2144434D; Thu, 13 Jul 2000 07:18:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id 8E38144336 for ; Thu, 13 Jul 2000 07:18:05 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nok.ntc.nokia.com [131.228.10.154]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id OAA09509 for ; Thu, 13 Jul 2000 14:18:03 +0300 (EETDST) From: christophe.bouret@nokia.com Received: from esebh01nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 13 Jul 2000 14:17:59 +0300 Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Thu, 13 Jul 2000 14:17:59 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1022F84E0@eseis04nok> To: sip@lists.bell-labs.com Date: Thu, 13 Jul 2000 14:17:58 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP Servlet API Status. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, I am looking at SIP Servlet API and would have liked to know what is the status of the document written by A. Kristensen and A. Byttner (draft-kristensen-sip-servlet-00.txt)? The API defined is good but need to be extended to support SDP for example. Thanks, Chris _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 07:52:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14146 for ; Thu, 13 Jul 2000 07:52:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4642344357; Thu, 13 Jul 2000 07:52:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (sasi.com [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id AFF5944336 for ; Thu, 13 Jul 2000 07:51:08 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id RAA16469 for ; Thu, 13 Jul 2000 17:20:34 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 13 Jul 2000 17:20:31 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id RAA00427 for ; Thu, 13 Jul 2000 17:20:07 +0530 (IST) Message-ID: <052a01bfecc0$590a81c0$8c40000a@sasi.com> From: "rafi" To: Date: Thu, 13 Jul 2000 17:19:05 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0527_01BFECEE.72906320" 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] On SIP-H323 Interworking Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0527_01BFECEE.72906320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Following are my understanding when a call is established=20 from H.323 terminal to a SIP terminal ( draft-singh-sip-h323-01.txt). Following could be the call flow diagram for such a call setup. (Assuming no faststart in the SetUp message) =20 SIP IWF GK H323Terminal Terminal GRQ <--------------- GCF ----------------> RRQ <---------------- RCF -----------------> ARQ <---------------- ACF -----------------> =20 SETUP <------------------------------ ARQ -----------> ACF <----------- INVITE(SDP=3DC) <---------------- 200 OK (SDP=3DC1) -------------------> ACK <------------------ TCS ( Cap=3DC1) --------------------------------> TCS ACK <------------------------------- TCS (Cap =3D C2) <------------------------------- TCS ACK -------------------------------> /* MSD is not shown */ OLC --------------------------------> OLC ACK <-------------------------------- OLC <-------------------------------- OLC ACK ---------------------------------> INVITE ( Cap =3D C3) <--------------------- 183 ----------------------> Alerting ----------------------------------> 200 OK ---------------------> CONNECT --------------------------------> ACK <----------------------- =20 Following are the difficulties with the above type of call set up. (i) IWF must know default capability set of H323 terminal. There=20 is no way to know actual capabilities in H323 without = establishing=20 the call. (ii) The capability final agreed upon by the Terminals (C3) is always a subset of C ( default capability), thus making selection of = C =20 a critical one. (iiI) When a call is established initially at SIP Terminal ( first ACK), H323 terminal MAY miss the media info. In RFC2543bis sending empty SDP is allowed in INVITE message. Thus instead of above call scenario can we have call flow something=20 like this SIP IWF GK H323Terminal GRQ <-------------------- GCF ------------------------> RRQ <----------------------- RCF ------------------------> ARQ <------------------------ ACF ------------------------> =20 SETUP <----------------------------------- ARQ -----------> ACF <----------- INVITE(SDP=3D0) <---------------- 200 OK (SDP=3DC) -------------------> TCS ( Cap=3DC) -------------------------------> TCS ACK <------------------------------- TCS (Cap =3D C1) <------------------------------- TCS ACK -------------------------------> =20 /* MSD is not shown */ OLC --------------------------------> OLC ACK <-------------------------------- OLC <-------------------------------- OLC ACK ---------------------------------> CONNECT --------------------------------> ACK ( SDP =3D C2) C2 is the maximal subset of C and C1 <----------------------- Any comments? Regards Rafi Assadi H.M. ------=_NextPart_000_0527_01BFECEE.72906320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
 
Following are my understanding when a = call is=20 established
from H.323 terminal to a SIP terminal (=20 draft-singh-sip-h323-01.txt).
Following could be  the call flow=20 diagram  for such a call setup.
(Assuming no  faststart in the = SetUp=20 message)
 
 
 
SIP         =20 IWF           =20 GK            = ;  =20 H323Terminal
Terminal
          &nbs= p;            = ;           =20 GRQ
           =             &= nbsp;   =20   =20 <---------------
        &n= bsp;           &nb= sp;           &nbs= p; =20 GCF
           =             &= nbsp;    =20   ---------------->
 
          &nbs= p;            = ;           =20 RRQ
           =             &= nbsp;    =20 <----------------
        &= nbsp;           &n= bsp;           &nb= sp; =20 RCF
           =             &= nbsp;   =20   ----------------->
 
          &nbs= p;            = ;           =20 ARQ
           =             &= nbsp;    =20 <----------------
        &= nbsp;           &n= bsp;           &nb= sp; =20 ACF
           =             &= nbsp;    =20 ----------------->
     =20
           &nb= sp;           =20 SETUP
          &nbs= p;     =20 <------------------------------
 
          &nbs= p;          =20 ARQ
           =        =20 ----------->
         =              = ACF
           =        =20 <-----------
 
   = INVITE(SDP=3DC)
 
 <----------------
 
   200 OK=20 (SDP=3DC1)
------------------->
 
  =20 ACK
<------------------
      &nbs= p;            = ;          =20 TCS (=20 Cap=3DC1)
          =          =20 -------------------------------->
     &nb= sp;           &nbs= p;           =20 TCS=20 ACK
           =         =20 <-------------------------------
 
          &nbs= p;            = ;      =20 TCS (Cap =3D=20 C2)
           =         =20 <-------------------------------
     &nbs= p;            = ;           =20 TCS=20 ACK
           =          =20 ------------------------------->
 
           &n= bsp;        =20 /* MSD is not shown */
 
          &nbs= p;            = ;       =20 OLC
           =          =20 -------------------------------->
     &nb= sp;           &nbs= p;            = ;=20 OLC=20 ACK
           =          =20 <--------------------------------
 
          &nbs= p;            = ;       =20 OLC
           =           =20 <--------------------------------
     &nb= sp;           &nbs= p;            = ;=20 OLC=20 ACK
           =           =20 --------------------------------->
 

   INVITE ( Cap =3D=20 C3)
<---------------------
 
     =20 183
---------------------->
      =             &= nbsp;           =20 Alerting
          &= nbsp;           =20 ---------------------------------->
 
    200=20 OK
 --------------------->      =  =20 CONNECT
          &n= bsp;           &nb= sp; =20 -------------------------------->
 
   =20 ACK
<-----------------------
      = ;          =20
 

   Following are the = difficulties=20 with the above type of call set up.
 
  (i)  IWF must know default = capability=20 set of H323 terminal. There
       is = no way=20 to  know actual capabilities in H323 without establishing =
       = the=20 call.
 
  (ii)  The capability final = agreed upon=20 by the Terminals (C3) is = always
       =20 a  subset of C ( default capability), thus  making selection = of=20 C 
        a critical=20 one.
 
  (iiI)   When  a = call is=20 established initially at SIP Terminal (=20 first
        ACK), H323 = terminal MAY=20 miss the media info.
 

   In RFC2543bis sending = empty SDP is=20 allowed  in INVITE message.
   Thus instead of above = call=20 scenario can we have call flow something
   like =20 this
 
SIP         =20 IWF           =20 GK            = ;  =20 H323Terminal
 
          &nbs= p;            = ;           =20 GRQ
           =             &= nbsp;      =20 <--------------------
       &nb= sp;           &nbs= p;            = ;  =20 GCF
           =             &= nbsp;      =20 ------------------------>
 
          &nbs= p;            = ;           =20 RRQ
           =             &= nbsp;      =20 <-----------------------
       =             &= nbsp;           &n= bsp;  =20 RCF
           =             &= nbsp;      =20 ------------------------>
 
          &nbs= p;            = ;           =20 ARQ
           =             &= nbsp;      =20 <------------------------
       = ;            =             &= nbsp;  =20 ACF
           =             &= nbsp;      =20 ------------------------>
    =20
           &nb= sp;           =20 SETUP
          &nbs= p;        =20 <-----------------------------------
 
          &nbs= p;          =20 ARQ
           =       =20 ----------->
         =              = ACF
           =       =20 <-----------
 
   = INVITE(SDP=3D0)
 
 <----------------
 
   200 OK=20 (SDP=3DC)
------------------->
 
          &nbs= p;            = ;      =20 TCS (=20 Cap=3DC)
          &= nbsp;          =20 ------------------------------->
     &nbs= p;            = ;           =20 TCS=20 ACK
           =          =20 <-------------------------------
 
          &nbs= p;            = ;      =20 TCS (Cap =3D=20 C1)
           =           =20 <-------------------------------
     &nbs= p;            = ;           =20 TCS=20 ACK
           =            =20 ------------------------------->
 
           &n= bsp;         =20
           &n= bsp;          =20 /* MSD is not shown */
 
 
          &nbs= p;            = ;       =20 OLC
           =            =20 -------------------------------->
     &nb= sp;           &nbs= p;            = ;=20 OLC=20 ACK
           =            =20 <--------------------------------
 
          &nbs= p;            = ;       =20 OLC
           =            =20 <--------------------------------
     &nb= sp;           &nbs= p;            = ;=20 OLC=20 ACK
           =            =20 --------------------------------->
 

          =             &= nbsp;     =20 CONNECT
          &n= bsp;           &nb= sp; =20 -------------------------------->
 
    ACK ( SDP =3D = C2)   C2=20 is the maximal subset of C and = C1
<-----------------------
 

  Any comments?
 

Regards
Rafi Assadi=20 H.M.
------=_NextPart_000_0527_01BFECEE.72906320-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 08:53:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16553 for ; Thu, 13 Jul 2000 08:53:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2465E44365; Thu, 13 Jul 2000 08:53:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mars.hss.co.in (unknown [202.54.26.197]) by lists.bell-labs.com (Postfix) with ESMTP id 69D4B44336 for ; Thu, 13 Jul 2000 08:52:49 -0400 (EDT) Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6DCqeg19753; Thu, 13 Jul 2000 07:52:49 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525691B.0045CC3D ; Thu, 13 Jul 2000 18:12:22 +0530 X-Lotus-FromDomain: HSS From: Arjun_Roychowdhury@hss.hns.com To: Jonathan Rosenberg Cc: rafi , sip@lists.bell-labs.com Message-ID: <6525691B.0045CA87.00@sandesh.hss.hns.com> Date: Thu, 13 Jul 2000 18:12:17 +0530 Subject: Re: [SIP] How to detect interworking ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Well, we did do a similar thing in our SIP-323 GW - we added a proprietary token that the signalling gateway would insert in one of the headers. However, it would be nice if we all had one "well known" way of doing it. Reason being that though the IWF box is a legit SIP UA on the SIP side, while developing one, we often put in only basic features (we just did a call setup and teardown) and dont want the end SIP UA to do more fancy stuff (like SIP call transfer etc) assuming it was a SIP-SIP call . Well, thats really an implementation ramble from this side, and our proprietary extension worked fine since we had HSS UAs too... So rafi, we faced the same issue (if thats what we would like to call it) - maybe some time down the line, when more people jump into implementing a SIP-H.323 GW, putting some fixed token with a fixed value to indicate a protcol X - SIP conversion would be nice. Regds Arjun Jonathan Rosenberg on 07/13/2000 11:39:33 AM To: rafi cc: sip@lists.bell-labs.com Subject: Re: [SIP] How to detect interworking ? By its nature such an interworking box appears as a perfectly legitimate SIP UA. So, from a pure protocol perspective, no. However, I have been updating the caller preferences spec. One of things I added is that you can use the new Contact parameters in the Contact in INVITE and 200 OK to convey useful info about who/what was contacted. One of the things that you can include is a textual description, so: 200 OK Contact: sip:iwf@columbia.edu;description="interworking with H.323" This is not useful for automated processing, but could allow the user to know. -Jonathan R. > rafi wrote: > > Hi, > > Is it not useful for a UAC to know whenever > there is an interworking taking place (For e.g. > SIP-H323)? Is it possible for a "gateway" to > indicate such information to UAC? > > Thank you > Rafi Assadi H.M -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 09:47:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18863 for ; Thu, 13 Jul 2000 09:47:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3602F44346; Thu, 13 Jul 2000 09:47:17 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from localhost.cisco.com (rtp-pv53-dhcp-131.cisco.com [161.44.53.131]) by lists.bell-labs.com (Postfix) with ESMTP id A4E0144336 for ; Thu, 13 Jul 2000 09:47:13 -0400 (EDT) Received: (from clindner@localhost) by localhost.cisco.com (8.9.3/8.9.3) id JAA02324; Thu, 13 Jul 2000 09:48:55 -0400 Date: Thu, 13 Jul 2000 09:48:54 -0400 From: Carl Lindner To: Ray Tayek Cc: sip@lists.bell-labs.com Subject: Re: [SIP] open source for sip? Message-ID: <20000713094854.A2309@clindner-lt.cisco.com> Reply-To: clindner@cisco.com Mail-Followup-To: Ray Tayek , sip@lists.bell-labs.com References: <4.2.0.58.20000712135628.00c06b10@netcom.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.2.0.58.20000712135628.00c06b10@netcom.netcom.com>; from rtayek@netcom.com on Wed, Jul 12, 2000 at 02:03:41PM -0700 X-Mailer: Mutt http://www.mutt.org/ X-Editor: Vim http://www.vim.org/ Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Take a look at www.vovida.com * Ray Tayek (rtayek@netcom.com) [000713 08:37]: > hi, i am developing an app that needs to support voip from one machine to > another (no phone system involved) (but possibly 3 party conversation). we > will have a quicknet internet phone jack card. > > i have used the open323 stuff to have a 2 way phone conversation, but h323 > seems like gross overkill and h323 will have lots of problems getting > through firewalls. > > i was hoping for something a bit simpler (maybe just some rtp stuff > restricted to a few ports?) > > is there open source project for sip out there? > > any pointers would be appreciated. > > thanks > > > --- > ray http://home.pacbell.net/rtayek/ > vice chair orange county java users group http://www.ocjug.org/ > hate spam? http://samspade.org/ssw/ > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 13 10:16:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20199 for ; Thu, 13 Jul 2000 10:16:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8345B4435E; Thu, 13 Jul 2000 10:15:38 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id D6F6444336 for ; Thu, 13 Jul 2000 10:15:34 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6DEF8M18094; Thu, 13 Jul 2000 16:15:09 +0200 (MEST) Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA24906; Thu, 13 Jul 2000 17:15:06 +0300 (EET DST) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id RAA08397; Thu, 13 Jul 2000 17:15:03 +0300 (EETDST) Message-ID: <396DCEDE.BF11E760@lmf.ericsson.se> Date: Thu, 13 Jul 2000 17:14:54 +0300 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: Jon.Peterson@Level3.com, sip@lists.bell-labs.com Subject: Re: [SIP] QoS & Third Party Call Control in SIP References: <87A245E94948D3118DE30008C716B01301523A03@c0005v1idc1.oss.level3.com> <3966BDE0.9EE131C7@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi Jonathan, I have put some call flows together and I have written a small internet draft with them. Until it appears in the archives it can be found at: http://www.hut.fi/~gonzalo/documents/draft-camarillo-3pcc-qos-00.txt This way we can discuss with concrete examples. Opinions? Thanks, Gonzalo Jonathan Rosenberg wrote: > > Jon.Peterson@Level3.com wrote: > > > > I have a question about the flow below. When C has acquired the provisional > > media (183) SDP from A, is that the time at which C would like to send an > > INVITE to B? Or would C rather wait until someone actually picks up the > > phone at A? Obviously, in a telephone-based service, if A has not yet > > answered when B starts ringing, this could lead to confusion, if the service > > is structured in such a way that the order of operations is important. > > Good observation. > > Interestingly, 3pcc as you have defined (INVITE the 2nd user once the > first answers) and preconditions fundamentally contradict each other. > Preconditions says that you don't send a 200 OK until resources are > reserved; but, you can't reserve resources until you have the address of > the other party with whom you are exchanging media. Getting this address > requires C to send an INVITE to the other party, so it can get back a > 183 with this information. This contradicts the type of 3pcc you desire, > where you don't want to send an INVITE to the the 2nd party until the > first answers with a 200 OK. > > Note that its not sending the INVITE which you really want to avoid, but > you want to make sure one phone rings only after the other has picked > up. This, actually, can be accomplished if we make COMET symmetrical, in > the sense that the caller and called party must both send each other > COMET in order to cause ringing at the other side. WIth this, A and B > will both eventually send COMET to C (note that neither A or B are > ringing). Now, C can send a COMET to A, and then wait for A to answer > the phone (200 OK), before sending a COMET to B. This causes As phone to > ring first, and then Bs phone to ring only after A picks up, as desired. > The reverse can also be accomplished. This allows control of the > ordering of ringing even with preconditions. > > This, however, is not how preconditions work now. Do people believe it > valuable to define such symmetry in order to enable this kind of 3pcc > service? > > 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: (732) 741-7244 > http://www.dynamicsoft.com -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 10:41:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21475 for ; Thu, 13 Jul 2000 10:41:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 409A144380; Thu, 13 Jul 2000 10:40:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 7BABD4435D for ; Thu, 13 Jul 2000 10:40:44 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id JAA01037; Thu, 13 Jul 2000 09:39:43 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jul 2000 09:34:13 -0500 Message-ID: From: "Culpepper, Bert" To: Jonathan Rosenberg , Christian Huitema Cc: sip@lists.bell-labs.com Subject: RE: [SIP] summary: DTMF and voice-over-packet Date: Thu, 13 Jul 2000 09:34:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com The technical issue with only carrying DTMF in RTP is that my media server just grew 7 to 10-fold in terms of media port (RTP port plus vocoder port) count. That's the increase in media port capacity my pre/post-paid calling card service node needs to provide an equivalent feature set and maintain the same overall call handling capacity it had in the PSTN. Is there a flaw in this logic? A call signaling message seems a lot more desirable to me. Regards, Bert Culpepper -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, July 11, 2000 11:45 PM To: Christian Huitema Cc: 'Kevin Davis'; sip@lists.bell-labs.com Subject: Re: [SIP] summary: DTMF and voice-over-packet Christian Huitema wrote: > > > From: Kevin Davis [mailto:Kevin_Davis@notes.teradyne.com] > > ... > > 4) Today, the telephone keypad interface is linked to DTMF. > > If or when this relationship should change is another > > matter. If it should change, it is still important to > > maintain compatibility with a huge installed base of DTMF. > > Nobody is proposing to cut support for DTMF. The argument is that, out of > two ways to support DTMF, the out of band solutions that include DTMF > translations in the signalling channel don't carry over to voice > recognition, while the in band solutions that establish a specific RTP leg > to the DTMF handler also work for voice recognition. Ergo, we should > consider that the "DTMF in RTP" solution is adequate and stop worrying about > the addition of DTMF verbs, or parameters, in SIP itself. Exactly. Well said. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 10:54:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22186 for ; Thu, 13 Jul 2000 10:54:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4CA5F44363; Thu, 13 Jul 2000 10:54:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id ED86444336 for ; Thu, 13 Jul 2000 10:54:38 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA21471; Thu, 13 Jul 2000 10:55:42 -0400 (EDT) Message-ID: <396DD8D2.77F9FD70@dynamicsoft.com> Date: Thu, 13 Jul 2000 10:57:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: Christian Huitema , sip@lists.bell-labs.com Subject: Re: [SIP] summary: DTMF and voice-over-packet References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Culpepper, Bert" wrote: > > The technical issue with only carrying DTMF in RTP is that > my media server just grew 7 to 10-fold in terms of media port > (RTP port plus vocoder port) count. That's the increase in > media port capacity my pre/post-paid calling card service > node needs to provide an equivalent feature set and maintain > the same overall call handling capacity it had in the PSTN. > > Is there a flaw in this logic? Yes. There are no ports here. All this comes in over IP, on an ethernet interface or what have you. There are NO DSP RESOURCES OR VOCODERS. The DTMF is already been detected. Its encapsulated in RTP in completely decoded form, EXACTLY THE SAME as you would get it in INFO. The difference as far as your platform is concerned, pretty much comes down to whether a DTMF digit arrives in a big packet on port 5060, or a smaller packet on a dynamic port. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 10:59:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22415 for ; Thu, 13 Jul 2000 10:59:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D80244399; Thu, 13 Jul 2000 10:57:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by lists.bell-labs.com (Postfix) with ESMTP id EB9EE4436F for ; Thu, 13 Jul 2000 10:57:40 -0400 (EDT) Received: from vovida.com (adsl-63-206-117-176.dsl.snfc21.pacbell.net [63.206.117.176]) by repulse.cnchost.com id KAA01235; Thu, 13 Jul 2000 10:57:28 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] From: skumar@vovida.com Message-ID: <396DB0CB.3D2415A9@vovida.com> Date: Thu, 13 Jul 2000 08:06:35 -0400 Organization: Vovida Networks X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dvir Oren Cc: SIP Subject: Re: [SIP] OK with no ACK References: <14692.37869.251930.807568@jodie.lucid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dvir: My understanding is , only requests are CANCELLED (i.e only the caller , since it sent an INVITE, can send a CANCEL) The gracefuly way for the callee to end the call will be to send a BYE, if it does not receive an ACK, after all of its retransmissions of 200 OK response. Hope that helps sunitha Dvir Oren wrote: > I think that a situation where the calle sent OK, but doesn't receive > ACK for an extended period of time should be handled. I'm > implementing a timeout on OK replies, that will kill the call if no > ACK was received after a defined period of time. > > My question is, should I send a CANCEL or a BYE? > > -- > Dvir Oren > Lucid VON Ltd. > 9 Saloniki St., Tel-Aviv Israel > Tel: +972 3 644 3038 Fax: +972 3 644 3039 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 11:40:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24716 for ; Thu, 13 Jul 2000 11:40:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23D984436F; Thu, 13 Jul 2000 11:40:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounce.harvard.net (bounce.harvard.net [140.239.141.158]) by lists.bell-labs.com (Postfix) with ESMTP id CB33644365 for ; Thu, 13 Jul 2000 11:40:42 -0400 (EDT) Received: from lockdown.harvard.net (miva-admin.harvard.net [140.239.141.145]) by bounce.harvard.net (8.10.1/8.10.1) with ESMTP id e6DFefO01769; Thu, 13 Jul 2000 11:40:41 -0400 Received: from flyhalf.PACTOLUS.com (wks194.pactolus.com [140.239.14.194] (may be forged)) by lockdown.harvard.net (8.9.3/8.9.3) with ESMTP id LAA23228; Thu, 13 Jul 2000 11:40:37 -0400 Received: by wks194.pactolus.com with Internet Mail Service (5.5.2650.21) id <3XYLZVZG>; Thu, 13 Jul 2000 11:50:36 -0400 Message-ID: <2CC2CB3C95C3D311ABAC009027DCD77E0AB9D0@wks194.pactolus.com> From: "Girzon, Gary" To: "'Jonathan Rosenberg'" , "Culpepper, Bert" Cc: Christian Huitema , sip@lists.bell-labs.com Subject: RE: [SIP] summary: DTMF and voice-over-packet Date: Thu, 13 Jul 2000 11:50:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I see a couple of problems with Jonathan's response - Does the RTP that comes into the Media Server have in-band audio as well? If yes, then my Media Server has to know to throw it away, If not, then the source of the RTP has to generate 2 distinct RTP streams - one with audio (and maybe DTMF events), one with only DTMF events. So while you don't need any DSP resources, you most certainly need additional network processing resources on both ends... Most Media Server (and Media Gateway) hardware architectures today split their ethernet pipes. There is typically one physical interface for the controlling protocol (like MGCP/ Megaco or even XML) and one for the streaming media (like RTP). So even though everything eventually flows through a single IP pipe, it makes sense to split the data since the media bandwidth is significantly higher. Furthermore, the protocol port is shared by all the media ports and is typically exposed only to another SIP server (ie., the Application Server). It does not have an RTP stack. In this architecture, maintaining RTP connection in the MS ports creates a significant overhead, as Bert has pointed out. And I am talking about Media Gateways/Servers that must support thousands of ports of media. Of course, if someone is building a Media Server with one big IP interface, coupled with super fast network processor / DSP farm, the RTP proposal may work. But such an architecture does not make economical sense today (hey, it's only year 2000! (-: ) Gary PS: regarding my first question, does RFC 2883 allow for sending only DTMF or tone information with no media data? > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, July 13, 2000 10:57 AM > To: Culpepper, Bert > Cc: Christian Huitema; sip@lists.bell-labs.com > Subject: Re: [SIP] summary: DTMF and voice-over-packet > > > > > "Culpepper, Bert" wrote: > > > > The technical issue with only carrying DTMF in RTP is that > > my media server just grew 7 to 10-fold in terms of media port > > (RTP port plus vocoder port) count. That's the increase in > > media port capacity my pre/post-paid calling card service > > node needs to provide an equivalent feature set and maintain > > the same overall call handling capacity it had in the PSTN. > > > > Is there a flaw in this logic? > > Yes. > > There are no ports here. All this comes in over IP, on an ethernet > interface or what have you. > > There are NO DSP RESOURCES OR VOCODERS. The DTMF is already been > detected. Its encapsulated in RTP in completely decoded form, EXACTLY > THE SAME as you would get it in INFO. > > The difference as far as your platform is concerned, pretty much comes > down to whether a DTMF digit arrives in a big packet on port > 5060, or a > smaller packet on a dynamic port. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 11:49:34 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25138 for ; Thu, 13 Jul 2000 11:49:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5D0C4439A; Thu, 13 Jul 2000 11:48:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DDBD044336 for ; Thu, 13 Jul 2000 11:48:14 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA19572; Thu, 13 Jul 2000 11:48:14 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA14209; Thu, 13 Jul 2000 11:48:04 -0400 (EDT) Message-ID: <396DE4B3.D8F3DB61@cs.columbia.edu> Date: Thu, 13 Jul 2000 11:48:03 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Girzon, Gary" Cc: "'Jonathan Rosenberg'" , "Culpepper, Bert" , Christian Huitema , sip@lists.bell-labs.com Subject: Re: [SIP] summary: DTMF and voice-over-packet References: <2CC2CB3C95C3D311ABAC009027DCD77E0AB9D0@wks194.pactolus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Girzon, Gary" wrote: > > I see a couple of problems with Jonathan's response - > > Does the RTP that comes into the Media Server have in-band audio > as well? If yes, then my Media Server has to know to throw it away, > If not, then the source of the RTP has to generate 2 distinct RTP streams > - one with audio (and maybe DTMF events), one with only DTMF events. > So while you don't need any DSP resources, you > most certainly need additional network processing resources on both ends... No. In either case, the box that does DTMF detection generates two streams: one for audio (plus DTMF), one for DTMF. The only difference is the packet format. > > Most Media Server (and Media Gateway) hardware architectures today > split their ethernet pipes. There is typically one physical interface > for the controlling protocol (like MGCP/ Megaco or even XML) and one for the > > streaming media (like RTP). So even though everything eventually flows > through a single IP pipe, it makes sense to split the data since > the media bandwidth is significantly higher. Furthermore, the protocol port > is shared by all the media ports and is typically exposed only to another > SIP > server (ie., the Application Server). It does not have an RTP stack. See below on "stack". Even with two different interfaces, there's presumably one processor or at least two tightly coupled processors, running the same OS and code, so even if you wanted to use an RTP stack, you would have one sitting around in the neighborhood. > In this architecture, maintaining RTP connection in the MS ports creates > a significant overhead, as Bert has pointed out. And I am talking about > Media Gateways/Servers that must support thousands of ports of media. There are no "ports of media" here. > > Of course, if someone is building a Media Server with one big IP interface, > coupled with super fast network processor / DSP farm, the RTP proposal may > work. > But such an architecture does not make economical sense today (hey, it's > only > year 2000! (-: ) > > Gary > > PS: regarding my first question, does RFC 2883 allow for sending only DTMF > or tone information with no media data? > Yes, you can send just DTMF. It seems to make very little difference to the sender whether you encapsulate tones in SIP INFO messages or RTP packets, in terms of processing resources. The only advantage is that the MG presumably already knows RTP (but probably has no clue about SIP). Implementing an RTP receiver for DTMF is probably a one-day project. You don't need an RTP stack for that, just some socket programming. -- 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 Jul 13 12:06:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25928 for ; Thu, 13 Jul 2000 12:06:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B97C9443AC; Thu, 13 Jul 2000 12:05:41 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounce.harvard.net (bounce.harvard.net [140.239.141.158]) by lists.bell-labs.com (Postfix) with ESMTP id AA97844390 for ; Thu, 13 Jul 2000 12:05:37 -0400 (EDT) Received: from lockdown.harvard.net (miva-admin.harvard.net [140.239.141.145]) by bounce.harvard.net (8.10.1/8.10.1) with ESMTP id e6DG5WO10183; Thu, 13 Jul 2000 12:05:32 -0400 Received: from flyhalf.PACTOLUS.com (wks194.pactolus.com [140.239.14.194] (may be forged)) by lockdown.harvard.net (8.9.3/8.9.3) with ESMTP id MAA23537; Thu, 13 Jul 2000 12:05:26 -0400 Received: by wks194.pactolus.com with Internet Mail Service (5.5.2650.21) id <3XYLZVZR>; Thu, 13 Jul 2000 12:15:25 -0400 Message-ID: <2CC2CB3C95C3D311ABAC009027DCD77E0AB9D1@wks194.pactolus.com> From: "Girzon, Gary" To: "'Henning Schulzrinne'" Cc: "'Jonathan Rosenberg'" , "Culpepper, Bert" , Christian Huitema , sip@lists.bell-labs.com Subject: RE: [SIP] summary: DTMF and voice-over-packet Date: Thu, 13 Jul 2000 12:15:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] ... > >"Girzon, Gary" wrote: > > ... > > Most Media Server (and Media Gateway) hardware architectures today > > split their ethernet pipes. There is typically one physical > interface > > for the controlling protocol (like MGCP/ Megaco or even > XML) and one for the > > > > streaming media (like RTP). So even though everything > eventually flows > > through a single IP pipe, it makes sense to split the data since > > the media bandwidth is significantly higher. Furthermore, > the protocol port > > is shared by all the media ports and is typically exposed > only to another > > SIP > > server (ie., the Application Server). It does not have an RTP stack. > > See below on "stack". Even with two different interfaces, there's > presumably one processor or at least two tightly coupled processors, > running the same OS and code, so even if you wanted to use an > RTP stack, > you would have one sitting around in the neighborhood. > Actually, I would guess that in the Media Gateways / Servers build around cards from NMS, AudioCodes, Intel/Dialogic, Brooktrout, etc., RTP runs on board (ie., is embedded) while the MGCP runs on the host (typically Pentium/SPARC). Some people may even be doing RTP in DSPs which are distributed. So these processors are not tighly coupled at all. Please correct me if I am wrong. > > In this architecture, maintaining RTP connection in the MS > ports creates > > a significant overhead, as Bert has pointed out. And I am > talking about > > Media Gateways/Servers that must support thousands of ports > of media. > > There are no "ports of media" here. What do you mean by that? > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > Thanks for answering the RTP question! Gary Girzon _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 13:01:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29145 for ; Thu, 13 Jul 2000 13:01:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1649144378; Thu, 13 Jul 2000 13:00:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7]) by lists.bell-labs.com (Postfix) with ESMTP id 94C7544336 for ; Thu, 13 Jul 2000 13:00:36 -0400 (EDT) Received: from luan (a98.vovida.com [209.237.8.98] (may be forged)) by illustrious.cnchost.com id NAA13080; Thu, 13 Jul 2000 13:00:14 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Reply-To: From: "Luan Dang" To: "Ray Tayek" , Subject: RE: [SIP] open source for sip? Date: Thu, 13 Jul 2000 10:01:14 -0700 Message-ID: <001301bfeceb$f40c9c00$2a05a8c0@private.vovida.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <4.2.0.58.20000712135628.00c06b10@netcom.netcom.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Ray, Please take a look at http://www.vovida.com/content.cfm?pagename=opensource We have SIP and RTP stacks that is open source that will work with the Quicknet Phone Jack card that you already have. -- Luan Dang Senior VP & CTO mailto:ldang@vovida.com Vovida Networks, Inc. voice:(408)383-1060 http://www.vovida.com fax:(408)383-1062 > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Ray Tayek > Sent: Wednesday, July 12, 2000 2:04 PM > To: sip@lists.bell-labs.com > Subject: [SIP] open source for sip? > > > hi, i am developing an app that needs to support voip from one machine to > another (no phone system involved) (but possibly 3 party > conversation). we > will have a quicknet internet phone jack card. > > i have used the open323 stuff to have a 2 way phone conversation, > but h323 > seems like gross overkill and h323 will have lots of problems getting > through firewalls. > > i was hoping for something a bit simpler (maybe just some rtp stuff > restricted to a few ports?) > > is there open source project for sip out there? > > any pointers would be appreciated. > > thanks > > > --- > ray http://home.pacbell.net/rtayek/ > vice chair orange county java users group http://www.ocjug.org/ > hate spam? http://samspade.org/ssw/ > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/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 Jul 13 14:07:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03438 for ; Thu, 13 Jul 2000 14:07:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ECE7144365; Thu, 13 Jul 2000 14:07:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id B237744336 for ; Thu, 13 Jul 2000 14:07:40 -0400 (EDT) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id NAA03999; Thu, 13 Jul 2000 13:08:00 -0500 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jul 2000 13:02:29 -0500 Message-ID: From: "Culpepper, Bert" To: "Girzon, Gary" Cc: "'Henning Schulzrinne'" , sip@lists.bell-labs.com Subject: RE: [SIP] summary: DTMF and voice-over-packet Date: Thu, 13 Jul 2000 13:02:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com See my comments on your first point below. > -----Original Message----- > From: Girzon, Gary [mailto:ggirzon@pactolus.com] > ... > > -----Original Message----- > > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > ... > > >"Girzon, Gary" wrote: > > > > ... > > > Most Media Server (and Media Gateway) hardware architectures today > > > split their ethernet pipes. There is typically one physical interface > > > for the controlling protocol (like MGCP/ Megaco or even XML) and one for the > > > streaming media (like RTP). So even though everything eventually flows > > > through a single IP pipe, it makes sense to split the data since > > > the media bandwidth is significantly higher. Furthermore, the protocol port > > > is shared by all the media ports and is typically exposed only to another > > > SIP server (ie., the Application Server). It does not have an RTP stack. > > > > See below on "stack". Even with two different interfaces, there's > > presumably one processor or at least two tightly coupled processors, > > running the same OS and code, so even if you wanted to use an > > RTP stack, > > you would have one sitting around in the neighborhood. > > > > Actually, I would guess that in the Media Gateways / Servers build around > cards from NMS, AudioCodes, Intel/Dialogic, Brooktrout, etc., RTP runs on > board (ie., is embedded) while the MGCP runs on the host (typically > Pentium/SPARC). > Some people may even be doing RTP in DSPs which are distributed. > So these processors are not tighly coupled at all. > > Please correct me if I am wrong. > What I think needs to be done is a separate NIC (standard/low cost board) in the media server (or better yet in the app server) that is used for processing RFC 2833 DTMF packets. The call leg can be distinguished by the port the packets arrive on (since the port was provided in the SDP component in the SIP message). As Henning said, only some socket (and RFC 2833 decoding) programming is needed. This removes the dependency on 3rd party component functionality. As for the practical aspect, finding gateways/terminals that support sending DTMF separate (via RFC 2833) from the primary media stream may be a trick. But I would guess that there's at least two implementations somewhere since the method has obtained RFC status. > > > In this architecture, maintaining RTP connection in the MS ports creates > > > a significant overhead, as Bert has pointed out. And I am talking about > > > Media Gateways/Servers that must support thousands of ports of media. > > > > There are no "ports of media" here. > > What do you mean by that? > > > > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > Thanks for answering the RTP question! > > Gary Girzon > Regards, Bert Culpepper _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 15:54:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07600 for ; Thu, 13 Jul 2000 15:54:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9CF9044370; Thu, 13 Jul 2000 15:54:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 611B94434D for ; Thu, 13 Jul 2000 15:54:29 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA24184; Thu, 13 Jul 2000 15:55:55 -0400 (EDT) Message-ID: <396E1E19.615FF589@dynamicsoft.com> Date: Thu, 13 Jul 2000 15:52:57 -0400 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: christophe.bouret@nokia.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Servlet API Status. References: <01D91AFB08B6D211BFD00008C7EABAE1022F84E0@eseis04nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit christophe.bouret@nokia.com wrote: > > Hi, > > I am looking at SIP Servlet API and would have liked to know what is the > status of the document written by A. Kristensen and A. Byttner > (draft-kristensen-sip-servlet-00.txt)? It's alive and well - even though it's expired. As you point out it does need to be updated in a number of ways, though, some of them which are mentioned in the issues section. > The API defined is good but need to > be extended to support SDP for example. Yes, and that will happen at some point. 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 Jul 13 18:04:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22100 for ; Thu, 13 Jul 2000 18:04:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 30B4944385; Thu, 13 Jul 2000 18:03:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 6420244336 for ; Thu, 13 Jul 2000 18:03:52 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA02514; Thu, 13 Jul 2000 18:03:49 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA15674; Thu, 13 Jul 2000 18:03:51 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3VHKV0B7>; Thu, 13 Jul 2000 18:03:36 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF67854B@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , "Culpepper, Bert" Cc: Christian Huitema , sip@lists.bell-labs.com Subject: RE: [SIP] summary: DTMF and voice-over-packet Date: Thu, 13 Jul 2000 18:03:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com I think that we have some confusion here on where the DTMF decoders are. Jonathan is assuming they are in the UAS. Some of the questions indicate that others are imagining that they are in the media server. The beauty of the "do it in RTP" approach that Jonathan is advocating is that IT DOESN'T MATTER! If the UAS has DTMF detection, send the RTP streams with the DTMF codec. If the UAS does not have DTMF detection, send the RTP streams with an audio codec. In the latter case, yes, you are tying up resources in the media server. That is EXACTLY how current systems which allow long DTMF tones do it. There is a system DTMF receiver on line for the whole call. It's usually in the debit card processors' switch. If you want to save media server resources, you have to move the DTMF detection into the UAS. If it is there (and of course on-line for the whole time), it can send RTP with DTMF codec to the media server (or a proxy server if you prefer). And, of course, if you are with Christian, you would do both; send the audio streams to the media server for speech recognition and send the DTMF streams for the DTMF. Of course, some day, we will probably have a phoneme codec, and things will be a little more interesting :) The UAS could, if you wanted it to, actually disconnect from the media server, and when it saw a tone, reconnect. I wouldn't advocate doing it, but you could. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, July 13, 2000 10:57 AM > To: Culpepper, Bert > Cc: Christian Huitema; sip@lists.bell-labs.com > Subject: Re: [SIP] summary: DTMF and voice-over-packet > > > > > "Culpepper, Bert" wrote: > > > > The technical issue with only carrying DTMF in RTP is that > > my media server just grew 7 to 10-fold in terms of media port > > (RTP port plus vocoder port) count. That's the increase in > > media port capacity my pre/post-paid calling card service > > node needs to provide an equivalent feature set and maintain > > the same overall call handling capacity it had in the PSTN. > > > > Is there a flaw in this logic? > > Yes. > > There are no ports here. All this comes in over IP, on an ethernet > interface or what have you. > > There are NO DSP RESOURCES OR VOCODERS. The DTMF is already been > detected. Its encapsulated in RTP in completely decoded form, EXACTLY > THE SAME as you would get it in INFO. > > The difference as far as your platform is concerned, pretty much comes > down to whether a DTMF digit arrives in a big packet on port > 5060, or a > smaller packet on a dynamic port. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 18:30:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29500 for ; Thu, 13 Jul 2000 18:30:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A74244390; Thu, 13 Jul 2000 18:30:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by lists.bell-labs.com (Postfix) with ESMTP id AE7B544336 for ; Thu, 13 Jul 2000 18:30:05 -0400 (EDT) Received: from ss8networks.com (gw-ss8networks.storm.ca [209.87.234.122]) by tonnant.cnchost.com id SAA04803; Thu, 13 Jul 2000 18:30:02 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <396E427E.B915975@ss8networks.com> Date: Thu, 13 Jul 2000 18:28:14 -0400 From: Dave Walker X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP MIB Mailing List , SIP Mailing List Cc: Kevin Lingle , Joon Maeng , Jonathan Rosenberg , Joerg Ott , Dean Willis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] revised SIP MIB draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Dear All, We have completed another revision of the SIP MIB and sent it to the IETF. To bypass the backlog, you can access it at http://www.ss8networks.com/files/internet-drafts/draft-ietf-sip-mib-01.txt Regards, Dave Walker SS8 Networks Ottawa, Canada _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 18:39:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01600 for ; Thu, 13 Jul 2000 18:38:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B930D44392; Thu, 13 Jul 2000 18:38:55 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 92E0F4433B for ; Thu, 13 Jul 2000 18:38:52 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA25582; Thu, 13 Jul 2000 18:40:20 -0400 (EDT) Message-ID: <396E45B7.87FC11BC@dynamicsoft.com> Date: Thu, 13 Jul 2000 18:41:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Cc: "Culpepper, Bert" , Christian Huitema , sip@lists.bell-labs.com Subject: Re: [SIP] summary: DTMF and voice-over-packet References: <4FBEA8857476D311A03300204840E1CF67854B@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Just a correction - I think Brian means UAC, not UAS. The UAC is the one sending the RTP. -Jonathan R. "Rosen, Brian" wrote: > > I think that we have some confusion here on where the > DTMF decoders are. Jonathan is assuming they are > in the UAS. Some of the questions indicate that > others are imagining that they are in the media server. > > The beauty of the "do it in RTP" approach that Jonathan > is advocating is that IT DOESN'T MATTER! > > If the UAS has DTMF detection, send the RTP streams with > the DTMF codec. > > If the UAS does not have DTMF detection, send the RTP > streams with an audio codec. > > In the latter case, yes, you are tying up resources in > the media server. That is EXACTLY how current systems > which allow long DTMF tones do it. There is a system DTMF > receiver on line for the whole call. It's usually in the > debit card processors' switch. If you want to save > media server resources, you have to move the DTMF detection > into the UAS. If it is there (and of course on-line for > the whole time), it can send RTP with DTMF codec to > the media server (or a proxy server if you prefer). > > And, of course, if you are with Christian, you would do both; > send the audio streams to the media server for speech recognition > and send the DTMF streams for the DTMF. Of course, some day, > we will probably have a phoneme codec, and things will be > a little more interesting :) > > The UAS could, if you wanted it to, actually disconnect > from the media server, and when it saw a tone, reconnect. > I wouldn't advocate doing it, but you could. > > Brian > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, July 13, 2000 10:57 AM > > To: Culpepper, Bert > > Cc: Christian Huitema; sip@lists.bell-labs.com > > Subject: Re: [SIP] summary: DTMF and voice-over-packet > > > > > > > > > > "Culpepper, Bert" wrote: > > > > > > The technical issue with only carrying DTMF in RTP is that > > > my media server just grew 7 to 10-fold in terms of media port > > > (RTP port plus vocoder port) count. That's the increase in > > > media port capacity my pre/post-paid calling card service > > > node needs to provide an equivalent feature set and maintain > > > the same overall call handling capacity it had in the PSTN. > > > > > > Is there a flaw in this logic? > > > > Yes. > > > > There are no ports here. All this comes in over IP, on an ethernet > > interface or what have you. > > > > There are NO DSP RESOURCES OR VOCODERS. The DTMF is already been > > detected. Its encapsulated in RTP in completely decoded form, EXACTLY > > THE SAME as you would get it in INFO. > > > > The difference as far as your platform is concerned, pretty much comes > > down to whether a DTMF digit arrives in a big packet on port > > 5060, or a > > smaller packet on a dynamic port. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 19:19:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14507 for ; Thu, 13 Jul 2000 19:19:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94D16443A5; Thu, 13 Jul 2000 19:19:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id D7FC644336 for ; Thu, 13 Jul 2000 19:19:42 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TLQDP>; Thu, 13 Jul 2000 16:19:35 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8AEB@sd_exchange.nuera.com> From: "Fox, Mike" To: sip@lists.bell-labs.com Date: Thu, 13 Jul 2000 16:19:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] How many RTP streams? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Just how many 2833 RTP streams should a UAC support? In terms of "best practices" should each SIP Application Server (SAS) taking part in a session receive it's own 2833 stream from the UAC, or should each application server forward the stream to the next inline SAS? Forwarding would allow for some feature interaction reduction by deleting recognized events and not forwarding them to down stream devices, of course this adds delay. Perhaps it would be helpful if a SAS could recognize the degree of delay sensitivity in downstream devices. By limiting the number of 2833 and media RTP streams a device emits, it may make for a more scaleable, less expensive to implement, and less prone to denial of service attacks solution. On a similar topic, is it possible that one could mount a denial of service attack against a specific host by leveraging the fact that a few bits of call control to a lot of gateways could direct megabits bits of media traffic towards a victim host? Comments? Mike Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Jul 13 19:49:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23363 for ; Thu, 13 Jul 2000 19:49:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 84BE04439C; Thu, 13 Jul 2000 19:49:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 3824644370 for ; Thu, 13 Jul 2000 19:49:02 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA16867 for ; Thu, 13 Jul 2000 19:49:01 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA25626 for ; Thu, 13 Jul 2000 19:49:01 -0400 (EDT) Message-ID: <396E556D.7F925422@cs.columbia.edu> Date: Thu, 13 Jul 2000 19:49:01 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Early version of draft on SIP for 911 services Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit See http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sip-911-00.pdf Comments are much appreciated. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 14 02: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 ESMTP id CAA04737 for ; Fri, 14 Jul 2000 02:34:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DCCCE44370; Fri, 14 Jul 2000 02:33:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id A453944336 for ; Fri, 14 Jul 2000 02:32:50 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id MAA10523 for ; Fri, 14 Jul 2000 12:02:15 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 14 Jul 2000 12:02:14 +0000 (IST) Received: from localhost (srinath@localhost) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id MAA06988 for ; Fri, 14 Jul 2000 12:02:09 +0530 (IST) Date: Fri, 14 Jul 2000 12:02:09 +0530 (IST) From: A Srinath To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Authorization in the ACK Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Hi, Consider the following scenario User Agent A User Agent B INVITE ----------------> 401 Unauthorized <---------------- ACK ---------------> INVITE with Authorization ----------------> 200 OK <--------------- ACK ----------------> . . . Media Flow Started . . . BYE -----------------> 200 OK <---------------- The following questions arise. 1. Does User Agent A provide authentication in the first ACK. 2. Does the User Agent A provide authentication in the second ACK, BYE, and any other requests that it makes in between. if so what 'nonce' does it use. This is a problem in the case of ACK as we cannot respond with a 401 unauthorized to an ACK. In all other cases this can be done and a new 'nonce' given. If the ACK uses the 'nonce' of the previous INVITE then chance of replay attack is present. Please comment on this. regards, Srinath A Silicon Automation Systems Phone: 5276100, 5276108 extn 4220 #1309, 10th Main, HAL III Stage Bangalore 560 008, India _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 14 02:52:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11499 for ; Fri, 14 Jul 2000 02:52:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB109443B5; Fri, 14 Jul 2000 02:51:51 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0D92344336 for ; Fri, 14 Jul 2000 02:51:48 -0400 (EDT) Received: from dynamicsoft.com (1Cust218.tnt1.freehold.nj.da.uu.net [63.17.113.218]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA26299; Fri, 14 Jul 2000 02:51:45 -0400 (EDT) Message-ID: <396EB8E5.2447F43D@dynamicsoft.com> Date: Fri, 14 Jul 2000 02:53:25 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: A Srinath Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Authorization in the 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-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit A Srinath wrote: > > Hi, > Consider the following scenario > > User Agent A User Agent B > > INVITE > ----------------> > > 401 Unauthorized > <---------------- > > ACK > ---------------> > > INVITE with > Authorization > ----------------> > > 200 OK > <--------------- > > ACK > ----------------> > . > . > . > Media Flow Started > . > . > . > BYE > -----------------> > > 200 OK > <---------------- > > The following questions arise. > > 1. Does User Agent A provide authentication in the first ACK. No. > 2. Does the User Agent A provide authentication in the second > ACK, BYE, and any other requests that it makes in between. Yes. > if so what 'nonce' does it use. The one it received in the original 401. If its not acceptable anymore, the request is rejected with an updated nonce. > This is a problem in the case of ACK as we cannot respond with > a 401 unauthorized to an ACK. In all other cases this can be > done and a new 'nonce' given. If the ACK uses the 'nonce' of > the previous INVITE then chance of replay attack is present. This is a good point. In this case, I would say that a UAS has to accept ACKs (and ONLY ACKs) with stale nonces. This does enable replays of old ACK. But, so what? ACK is only useful to acknowledge an INVITE with a specific call-ID, To, From, CSeq. Since the Call-ID is chosen randomly, a UAC will never generate another INVITE with these same parameters. This means that the stale ACK can never be used to do anything useful anyway. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 14 03:06:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15777 for ; Fri, 14 Jul 2000 03:06:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8577443C1; Fri, 14 Jul 2000 03:05:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D63F0443B9 for ; Fri, 14 Jul 2000 03:05:05 -0400 (EDT) Received: from dynamicsoft.com (1Cust218.tnt1.freehold.nj.da.uu.net [63.17.113.218]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA26308; Fri, 14 Jul 2000 03:06:32 -0400 (EDT) Message-ID: <396EBC5C.1AF1246F@dynamicsoft.com> Date: Fri, 14 Jul 2000 03:08:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Williams Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Stateless Redirect Server? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit This is actually possible so long as (1) your redirect server never sends a provisional response, (2) your location service logic yields the same exact result when invoked with the same request. Request retransmissions will arrive at the server, and appear as new requests. These cause the location service lookup to be redone, and a new redirect response to be sent. This redirect response will be the same as previous ones from the same invite, thus resulting in triggered response retransmissions, and thus reliability. Sending a provisional response screws this up, since you will no longer get request retransmissions (for INVITE, at least). -Jonathan R. David Williams wrote: > > Overall, it appears that Redirect servers should behave statefully and > retransmit their final response. But is it also legal for them to > behave statelessly and only send a single final response? In a manner > similiar to that of a stateless proxy? > > Some relevant sections of the 2453bis: > > Section 12.1 (Behavior of Redirect Servers) says: "The Redirect > server maintains transaction state for the whole SIP transaction." > Section 10.1.2 (Responses) says: "Responses with status 300 and > higher are retransmitted by each stateful proxy or UAS until the next > upstream proxy or UAC sends an ACK or CANCEL." But no meantion of a > redirect server. > Section 10.5.1 (UDP) indicates that servers should reliably > retransmit responses. Without meantioning that stateless proxies > cannot. > > thanks, > -david > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 14 06:56:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10637 for ; Fri, 14 Jul 2000 06:56:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 647C444395; Fri, 14 Jul 2000 06:55:43 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 960F144336 for ; Fri, 14 Jul 2000 06:55:36 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10322; Fri, 14 Jul 2000 06:55:35 -0400 (EDT) Message-Id: <200007141055.GAA10322@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 14 Jul 2000 06:55:35 -0400 Subject: [SIP] I-D ACTION:draft-rosenberg-sip-hearingimpaired-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Enabled Services to Support the Hearing Impaired Author(s) : J. Rosenberg, H. Schulzrinne, H. Sinnreich Filename : draft-rosenberg-sip-hearingimpaired-00.txt Pages : 14 Date : 13-Jul-00 This document outlines a set of services enabled by the Session Initiation Protocol (SIP), that allow for access to voice services by people who are hearing impaired. SIP has gained much attention as a tool for voice communications on the Internet. Therefore, considerations for universal access of its services are important. This document does not propose any extensions or new capabilities to SIP, but rather a set of services enabled by it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hearingimpaired-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-hearingimpaired-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-hearingimpaired-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: <20000713145548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-hearingimpaired-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-hearingimpaired-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145548.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 Fri Jul 14 10:22:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09690 for ; Fri, 14 Jul 2000 10:22:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 51FA14434B; Fri, 14 Jul 2000 10:22:04 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id B416B44336 for ; Fri, 14 Jul 2000 10:22:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Jul 14 10:21:58 EDT 2000 Received: by lists.bell-labs.com (Postfix) id B06DB4435B; Fri, 14 Jul 2000 10:08:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from daimanta.ascend.com (unknown [152.148.40.20]) by lists.bell-labs.com (Postfix) with ESMTP id 3067C44347 for ; Fri, 14 Jul 2000 10:08:48 -0400 (EDT) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id KAA17750 for ; Fri, 14 Jul 2000 10:08:47 -0400 (EDT) Received: from lucent.com ([152.148.210.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id JAA19207 for ; Fri, 14 Jul 2000 09:47:47 -0400 (EDT) Message-ID: <396F1EED.2DFD6C4D@lucent.com> Date: Fri, 14 Jul 2000 10:08:46 -0400 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 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] A question about Stateful Proxies, Session Timers, and the Contact field Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hello -- I have a question about the following scenario. Proxy1<---->Proxy2 / \ Client1 Client2 Proxy1 and Proxy2 are stateful servers. Let me see if I understand what is happening correctly: C1 sends an INVITE to C2 with a Contact field indicating the location of C1. The INVITE travels C1->P1->P2->C2. C2 sends a 200 OK response with a Contact field containing the location of C2. The response travels C2->P2->P1->C1. C1 sends an ACK based on the Contact field it received in the 200 OK response, and the ACK travels C1->C2, bypassing the stateful proxies. Later on, when either C1 or C2 sends a BYE, they communicate directly with each other based on the contact field, also bypassing the stateful proxies. If this is correct, how do the stateful proxies ever know that the call has terminated? (i.e. to know when to stop billing, perhaps.) On the face of it, the Session Timer (draft-ietf-sip-session-timer-01.txt) idea sounds like a possibility, but I am not sure how the Session Timer should interact with the Contact field. That is, if C1 starts a call with a session timer and initially routes the message through Proxy1, then in the 200 response receives a Contact field with the direct location of C2, should it send the session refresh straight to C2? If so, Proxy1 and Proxy2 will never see the refreshes and are justified in sending a BYE request to the clients, if I understand the draft properly. This seems undesirable. On the other hand, if the session refreshes are to travel the same path as a fresh INVITE message, ignoring any information received in the Contact field in the response, doesn't this run into some issues with forking proxies and changing REGISTER requests? (i.e. Client2 sends a REGISTER to P2 that C2 is going to be in a conference room for the next 60 minutes. 55 minutes later, C2 receives a call with a session timer with an interval of one refresh every three minutes. 3 minutes into the call, the first refresh arrives. 5 minutes into the call, the REGISTERed location of C2 in the conference room expires. 6 minutes into the call the next session refresh is sent, and never reaches C2 because the INVITE routing has changed, so C2 terminates the call. (?)) Also, if a new REGISTER message came in with a higher preference during a call, and the session refresh INVITE was sent to the new destination (or forked), would the new client be able to recognize the refresh as a refresh and not as a new call? Perhaps instead of sending an INVITE as the session refresh, a client could send an ACK? The INVITE request by nature appears more oriented towards causing a change of state, whereas the ACK request seems to fit the role of (periodic) acknowledgement somewhat better. Any pointers to where this is clarified would be appreciated. The session timer draft (draft-ietf-sip-session-timer-01.txt) does not appear to mention the Contact header at all. Thank you, Kim Liu Software Engineer kliu@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 Fri Jul 14 10:54:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18753 for ; Fri, 14 Jul 2000 10:54:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E587443A8; Fri, 14 Jul 2000 10:53:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 0455444336 for ; Fri, 14 Jul 2000 10:53:13 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA12369; Fri, 14 Jul 2000 15:51:10 +0100 (BST) From: "Jo Hornsby" To: "Kim Liu" , Subject: RE: [SIP] A question about Stateful Proxies, Session Timers, and the Contact field Date: Fri, 14 Jul 2000 15:51:10 +0100 Message-ID: <000901bfeda2$f2a15f10$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: <396F1EED.2DFD6C4D@lucent.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Hello -- > > I have a question about the following scenario. > > Proxy1<---->Proxy2 > / \ > Client1 Client2 > > Proxy1 and Proxy2 are stateful servers. > > Let me see if I understand what is happening correctly: > > C1 sends an INVITE to C2 with a Contact field indicating the location > of C1. The INVITE travels C1->P1->P2->C2. C2 sends a 200 OK > response with a Contact field containing the location of C2. The > response travels C2->P2->P1->C1. Sounds good to me. > C1 sends an ACK based on the Contact field it received in the 200 OK > response, and the ACK travels C1->C2, bypassing the stateful proxies. > Later on, when either C1 or C2 sends a BYE, they communicate directly > with each other based on the contact field, also bypassing the > stateful proxies. Correct, with one caveat: Record-Route. (There are other instances such as organizations mandating the use of an outbound proxy, but typically you've just moved the problem one hop along.) > If this is correct, how do the stateful proxies > ever know that the call has terminated? (i.e. to know when to stop > billing, perhaps.) Call-Stateful proxies typically "enforce" their knowledge of callstate by means of the Record-Route header. I'll refrain from writing a boring essay on the subject -- it's well covered in the RFC -- save to say that Record-Routes are like Vias, except they are decremental rather than incremental. Note that "stateful" in the SIP sense doesn't require the proxies to be in the path of any subsequent requests for a call leg. All it means is that a server remembers a given request for some period of time (nominally based around the SIP retransmission timers). > On the face of it, the Session Timer > (draft-ietf-sip-session-timer-01.txt) > idea sounds like a possibility, but I am not sure how the Session > Timer should interact with the Contact field. Session-Timer doesn't have any impact on basic protocol operation; that is, clients send re-INVITEs to the same place as they always would. > That is, if C1 starts a call > with a session timer and initially routes the message through Proxy1, > then in the 200 response receives a Contact field with the direct > location of C2, should it send the session refresh straight to C2? > If so, Proxy1 and Proxy2 will never see the refreshes and are justified > in sending a BYE request to the clients, if I understand the draft > properly. This seems undesirable. This is correct (although proxies are not allowed to initiate BYE requests). If the proxies need to be in the signalling part, they should add Record-Route headers. > Perhaps instead of sending an INVITE > as the session refresh, a client could send an ACK? The INVITE > request by nature appears more oriented towards causing a change > of state, whereas the ACK request seems to fit the role of > (periodic) acknowledgement somewhat better. No. There is no need to use ACK since INVITE works perfectly well. Furthermore, ACK would be no better because it is subject to the same routing decisions as INVITE (when there is no obviously-related INVITE), and ACKs are unacknowledged, which would be unhelpful for the UAC. &:) HTH, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 14 11:40:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05564 for ; Fri, 14 Jul 2000 11:40:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 329BA443A3; Fri, 14 Jul 2000 11:40:05 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id D772644336 for ; Fri, 14 Jul 2000 11:40:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Jul 14 11:38:55 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 297154435C; Fri, 14 Jul 2000 11:25:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from daimanta.ascend.com (unknown [152.148.40.20]) by lists.bell-labs.com (Postfix) with ESMTP id 9321644347 for ; Fri, 14 Jul 2000 11:25:45 -0400 (EDT) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id LAA19221; Fri, 14 Jul 2000 11:25:44 -0400 (EDT) Received: from lucent.com ([152.148.210.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id LAA20054; Fri, 14 Jul 2000 11:04:45 -0400 (EDT) Message-ID: <396F30F7.1B365F74@lucent.com> Date: Fri, 14 Jul 2000 11:25:43 -0400 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: sip@lists.bell-labs.com Subject: Re: [SIP] A question about Stateful Proxies, Session Timers, and the Contact field References: <000901bfeda2$f2a15f10$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > Correct, with one caveat: Record-Route. (There are other instances > such as organizations mandating the use of an outbound proxy, but > typically you've just moved the problem one hop along.) Record-Route does not seem to be listed in Appendix A "Minimal Implementation" for basic clients. Should Record-Route be required to be understood by a minumal basic client implementation (as opposed to the firewall friendly one)? If not, then the use of Record-Route is not going to be an assured solution. Otherwise, sure. Out of curiosity, are there going to be options to allow for the encryption of the Record-Route path the same where you can Hide Via headers, so that if you are trying to hide the route taken by a message across your internal network of stateful proxies you can? > > On the face of it, the Session Timer > > (draft-ietf-sip-session-timer-01.txt) > > idea sounds like a possibility, but I am not sure how the Session > > Timer should interact with the Contact field. > > Session-Timer doesn't have any impact on basic protocol operation; > that is, clients send re-INVITEs to the same place as they always > would. I assume that the re-INVITEs would then follow the route from the Record-Route header (if available) to route the re-INVITEs to avoid issues such as forking proxies, changing registrations, etc? Okay, that works for me, as long as all clients understand Record-Route. Thanks for the clarifications, Kim Kim Liu Software Engineer Kliu@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 Fri Jul 14 11:53:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10898 for ; Fri, 14 Jul 2000 11:53:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4AEE443C0; Fri, 14 Jul 2000 11:53:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 79D2044388 for ; Fri, 14 Jul 2000 11:52:58 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA01311; Fri, 14 Jul 2000 16:51:05 +0100 (BST) From: "Jo Hornsby" To: "Kim Liu" Cc: Subject: RE: [SIP] A question about Stateful Proxies, Session Timers, and the Contact field Date: Fri, 14 Jul 2000 16:51:06 +0100 Message-ID: <000a01bfedab$51f897a0$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: <396F30F7.1B365F74@lucent.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Record-Route does not seem to be listed in Appendix A "Minimal > Implementation" for basic clients. Should Record-Route be required to > be understood by a minumal basic client implementation (as opposed to > the firewall friendly one)? If not, then the use of Record-Route is > not going to be an assured solution. Otherwise, sure. This is a good point; I even note that obeying Route: is only a SHOULD. It's quite difficult to enforce that a UA/proxy/whatever obeys Record-Route/Route without resorting to some sort of notion of servers only accepting requests for trusted hosts/domains, or something. I guess from an organizational point-of-view, you can put firewalls at all the salient points, then your ALG-cognizant proxies mandate themselves by virtue of the fact that only they can open up the holes. One solution is to sit lightweight proxies (which are known to obey Route headers) in front of UAs, but I guess what it comes down to is that you ensure you buy from a vendor that does the Right Thing. > Out of curiosity, are there going to be options to allow for the > encryption of the Record-Route path the same where you can Hide > Via headers, so that if you are trying to hide the route taken by a > message across your internal network of stateful proxies you can? I'm not really in a position to comment on this &:), although do I dimly remember some discussion from the 4th Bake-Off? (I'm actually struggling to see how this could possibly work...although perhaps if UAC and UAS were presented with headers encrypted in the appropriate "direction"...Hmmm....) > I assume that the re-INVITEs would then follow the route from the > Record-Route header (if available) to route the re-INVITEs to avoid > issues such as forking proxies, changing registrations, etc? Okay, > that works for me, as long as all clients understand Record-Route. Indeed. - 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 Jul 14 12: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 ESMTP id MAA19173 for ; Fri, 14 Jul 2000 12:19:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 17DCA443CA; Fri, 14 Jul 2000 12:18:06 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 5D4AF44336 for ; Fri, 14 Jul 2000 12:18:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jul 14 12:16:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2073B4435C; Fri, 14 Jul 2000 12:03:19 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from daimanta.ascend.com (unknown [152.148.40.20]) by lists.bell-labs.com (Postfix) with ESMTP id 91BEC44347 for ; Fri, 14 Jul 2000 12:03:18 -0400 (EDT) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id MAA19925; Fri, 14 Jul 2000 12:03:18 -0400 (EDT) Received: from lucent.com ([152.148.210.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id LAA20481; Fri, 14 Jul 2000 11:42:18 -0400 (EDT) Message-ID: <396F39C5.C3E56A22@lucent.com> Date: Fri, 14 Jul 2000 12:03:17 -0400 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: sip@lists.bell-labs.com Subject: Re: [SIP] A question about Stateful Proxies, Session Timers, and the Contact field References: <000a01bfedab$51f897a0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > Record-Route does not seem to be listed in Appendix A "Minimal > > Implementation" for basic clients. Should Record-Route be required to > > be understood by a minumal basic client implementation (as opposed to > > the firewall friendly one)? If not, then the use of Record-Route is > > not going to be an assured solution. Otherwise, sure. > > This is a good point; I even note that obeying Route: is only > a SHOULD. Hmm. Perhaps that as part of the session timer specfication it should be required that any client supporting the session timer must also support the route/record-route headers? Cheers, Kim Kim Liu Software Engineer _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 14 13:50:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18716 for ; Fri, 14 Jul 2000 13:50:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88243443A3; Fri, 14 Jul 2000 13:50:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mayo.cisco.com (mayo.cisco.com [161.44.3.207]) by lists.bell-labs.com (Postfix) with ESMTP id C0E4A44336 for ; Fri, 14 Jul 2000 13:50:02 -0400 (EDT) Received: from cisco.com (mayo.cisco.com [161.44.3.207]) by mayo.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA18626; Fri, 14 Jul 2000 13:46:03 -0400 (EDT) Message-ID: <396F51DA.F2081105@cisco.com> Date: Fri, 14 Jul 2000 13:46:03 -0400 From: Nilesh Trivedi Organization: Packet Development Unit X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Hide header processing. References: <001d01bfe6a3$b76795a0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Thanks Jo. Once previous Via (or recieved topmost via) is encrypted, and "hidden" parameter appended to the header and forwarded downstream, if the encrypted string contains characters such as ';' ',' which forms part of the header syntax, wouldn't the downstream proxy be confused? How is the parsing of encrypted Via's or hidden parameter handled? Have a good day!! Thanks, Nilesh. > > I have some basic doubts about Hide header processing at the proxy. > > Don't we all. &:) > > > The SIP specs say that a server hides the host and port parts of the > > top-most Via header if a request contains "Hide:hop" header field. > > > > This falls under hop-by-hop encryption since the proxy which > > encrypted it will be the one to decrypt it on response. But it also > > says that a server capable of hiding Via headers MUST attempt > > to decrypt all Via headers to do loop detection, if I have understood > > it correctly then this conflicts with the basic mechanism of hiding > > the previous Via. How does the proxy know in which form the Via's > > have been encrypted if it has to decrypt all of them? since they have > > not been encrypted by itself. > > I think the point is that if it does manage to decrypt a Via, then > the request is probably looped, because you wouldn't expect Proxy X > to be able to decrypt a Via encrypted by Proxy Y. (The recommentation > of adding "salt" is a good one, since it should go some way to > preventing instance 2 of Proxy X from decrypting a Via encrypted by > instance 1 of Proxy X.) > > Note that there are a few changes to loop detection as the result > of so-called "Legal Loops", and as such, just being able to decrypt > a Via does not necessarily imply that the request has looped. > (Working with the algorithm suggested in 6.47.5 of the most recent > bis (July), is one way to ensure that the request hasn't just > spiralled.) > > > Also, if an upstream agent is requesting Hide it does so assuming the > > proxy is capable of doing so, so what if the proxy is not capable of?. > > The useragent loses. There's no way to mandate it (I note it's > only a SHOULD). > > HTH, > > - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 14 16:37:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11694 for ; Fri, 14 Jul 2000 16:37:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BDF8C4439B; Fri, 14 Jul 2000 16:37:22 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from blanc.cisco.com (blanc.cisco.com [161.44.3.203]) by lists.bell-labs.com (Postfix) with ESMTP id 29F9C44336 for ; Fri, 14 Jul 2000 16:37:19 -0400 (EDT) Received: (ddaiker@localhost) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id QAA07085; Fri, 14 Jul 2000 16:33:36 -0400 (EDT) From: David Daiker Message-Id: <200007142033.QAA07085@blanc.cisco.com> To: jhornsby@ubiquity.net (Jo Hornsby) Date: Fri, 14 Jul 2000 16:33:36 -0400 (EDT) Cc: kliu@lucent.com (Kim Liu), sip@lists.bell-labs.com In-Reply-To: <000a01bfedab$51f897a0$4e34c3c1@ubiquity.co.uk> from "Jo Hornsby" at Jul 14, 2000 04:51:06 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Hide: header and record-route (was: A question about stateful proxies) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit What should be the interaction of record-route and hide:hop/route ? Should a proxy remove the 'hide:' header it it's going to turn on record-route ? or should proxies encrypt the previous hop route if they're handling requests and responses with privacy and a route header ? What were some of the comments at the bake-off ? thanks, david > > Out of curiosity, are there going to be options to allow for the > > encryption of the Record-Route path the same where you can Hide > > Via headers, so that if you are trying to hide the route taken by a > > message across your internal network of stateful proxies you can? > > I'm not really in a position to comment on this &:), although do > I dimly remember some discussion from the 4th Bake-Off? (I'm > actually struggling to see how this could possibly work...although > perhaps if UAC and UAS were presented with headers encrypted in > the appropriate "direction"...Hmmm....) > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Jul 14 16:57:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18316 for ; Fri, 14 Jul 2000 16:57:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8CAA1443D1; Fri, 14 Jul 2000 16:56:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.bell-labs.com (Postfix) with ESMTP id 0A8E9443C1 for ; Fri, 14 Jul 2000 16:56:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02073; Fri, 14 Jul 2000 14:56:28 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA13261; Fri, 14 Jul 2000 13:56:27 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA27190; Fri, 14 Jul 2000 13:56:24 -0700 (PDT) Date: Fri, 14 Jul 2000 13:55:34 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" To: aaa-wg@merit.edu, sip@lists.bell-labs.com Cc: Pat.Calhoun@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [SIP] AAA/IP Telephony Requirements I-D Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com All, A few of us just sent out our first draft that lists some requirements for SIP and AAA. The intent of the draft is to understand the requirements, have them refined (and I am quite sure many new ones added over time), so that we can understand what is needed in an AAA protocol. Given that it will take some time before the draft is announced, and available, it can be found at www.cdma-2000.org/draft-calhoun-sip-aaa-reqs-00.txt. Comments are welcomed, and encouraged. Thanks, PatC _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Jul 15 15: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 ESMTP id PAA16880 for ; Sat, 15 Jul 2000 15:25:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 76C4344353; Sat, 15 Jul 2000 15:24:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id F12DF44337 for ; Sat, 15 Jul 2000 15:24:33 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA01930; Sat, 15 Jul 2000 15:24:32 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA13207; Sat, 15 Jul 2000 15:24:31 -0400 (EDT) Message-ID: <3970BA6F.F122BF5F@cs.columbia.edu> Date: Sat, 15 Jul 2000 15:24:31 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com, rem-conf@es.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] RFC 2833 ("tones") implementations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I would appreciate if implementors of RFC 2833 ("tones over RTP") could get in touch with me. I'd like to start identifying implementations and what features are used. Also, if anybody wants to support (or is already implementing) RTP (e.g., RFC 2833) over TCP, please let me know. -- 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 Jul 16 10: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 ESMTP id KAA18339 for ; Sun, 16 Jul 2000 10:32:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8345F4434A; Sun, 16 Jul 2000 10:31:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 49A8B44336 for ; Sun, 16 Jul 2000 10:31:34 -0400 (EDT) Received: from dynamicsoft.com (1Cust240.tnt4.farmingdale.ny.da.uu.net [63.23.220.240]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA00385; Sun, 16 Jul 2000 10:29:03 -0400 (EDT) Message-ID: <3971C720.21765E17@dynamicsoft.com> Date: Sun, 16 Jul 2000 10:30:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kim Liu Cc: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] A question about Stateful Proxies, Session Timers, and the Contact field References: <000a01bfedab$51f897a0$4e34c3c1@ubiquity.co.uk> <396F39C5.C3E56A22@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Kim Liu wrote: > > Jo Hornsby wrote: > > > > Record-Route does not seem to be listed in Appendix A "Minimal > > > Implementation" for basic clients. Should Record-Route be required to > > > be understood by a minumal basic client implementation (as opposed to > > > the firewall friendly one)? If not, then the use of Record-Route is > > > not going to be an assured solution. Otherwise, sure. > > > > This is a good point; I even note that obeying Route: is only > > a SHOULD. > > Hmm. Perhaps that as part of the session timer specfication it should be > required that any client supporting the session timer must also support > the route/record-route headers? I think whats needed is qualification in the draft about what you will get and be able to do with a minimal implementation. Client to client calls is one of them, but calling through proxies is likely to cause problems if you don't support record-route. For all intensive purposes its a MUST if you actually want someone to buy your product... -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Jul 16 10:33:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18805 for ; Sun, 16 Jul 2000 10:33:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C17464435D; Sun, 16 Jul 2000 10:33:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D09BD44350 for ; Sun, 16 Jul 2000 10:33:36 -0400 (EDT) Received: from dynamicsoft.com (1Cust240.tnt4.farmingdale.ny.da.uu.net [63.23.220.240]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA00393; Sun, 16 Jul 2000 10:31:21 -0400 (EDT) Message-ID: <3971C7AB.E36AF4C3@dynamicsoft.com> Date: Sun, 16 Jul 2000 10:33:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: Kim Liu , sip@lists.bell-labs.com Subject: Re: [SIP] A question about Stateful Proxies, Session Timers, and the Contact field References: <000a01bfedab$51f897a0$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > > Out of curiosity, are there going to be options to allow for the > > encryption of the Record-Route path the same where you can Hide > > Via headers, so that if you are trying to hide the route taken by a > > message across your internal network of stateful proxies you can? > > I'm not really in a position to comment on this &:), although do > I dimly remember some discussion from the 4th Bake-Off? (I'm > actually struggling to see how this could possibly work...although > perhaps if UAC and UAS were presented with headers encrypted in > the appropriate "direction"...Hmmm....) It just doesn't work. Unlike Via, where the encryption happens in one direction (downstream), and decryption in the other (upstream), Record-Route results in the construction of Route headers that are used for subsequent requests from called UA to calling UA, *AND* calling UA to called UA. This means you can't encrypt either the Record-Route before or after your own... -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 00: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 ESMTP id AAA04949 for ; Mon, 17 Jul 2000 00:14:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9CDB34434C; Mon, 17 Jul 2000 00:13:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 25C8D44336 for ; Mon, 17 Jul 2000 00:12:57 -0400 (EDT) Received: from dynamicsoft.com (1Cust91.tnt5.freehold.nj.da.uu.net [63.36.113.91]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01019; Mon, 17 Jul 2000 00:10:26 -0400 (EDT) Message-ID: <397287A7.A0D5C42D@dynamicsoft.com> Date: Mon, 17 Jul 2000 00:12:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nilesh Trivedi Cc: Jo Hornsby , sip@lists.bell-labs.com Subject: Re: [SIP] Hide header processing. References: <001d01bfe6a3$b76795a0$4e34c3c1@ubiquity.co.uk> <396F51DA.F2081105@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Nilesh Trivedi wrote: > > Thanks Jo. Once previous Via (or recieved topmost via) is encrypted, > and "hidden" parameter appended to the header and forwarded downstream, > if the encrypted string contains characters such as ';' ',' which forms > part of the header syntax, wouldn't the downstream proxy be confused? Its not allowed. Notice the BNF for Via: Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by *( ";" via-params ) [ comment ] ) via-params = via-hidden | via-ttl | via-maddr | via-received | via-branch via-hidden = "hidden" via-ttl = "ttl" "=" ttl via-maddr = "maddr" "=" maddr via-received = "received" "=" host via-branch = "branch" "=" token sent-protocol = protocol-name "/" protocol-version "/" transport protocol-name = "SIP" | token protocol-version = token transport = "UDP" | "TCP" | token sent-by = ( host [ ":" port ] ) | ( concealed-host ) concealed-host = token ttl = 1*3DIGIT ; 0 to 255 In particular, note: concealed-host = token which means the encrypted Via can't contain ; or any other separator. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 00:31:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09087 for ; Mon, 17 Jul 2000 00:31:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8173544359; Mon, 17 Jul 2000 00:30:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EF0BE44336 for ; Mon, 17 Jul 2000 00:30:41 -0400 (EDT) Received: from dynamicsoft.com (1Cust91.tnt5.freehold.nj.da.uu.net [63.36.113.91]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01060 for ; Mon, 17 Jul 2000 00:32:12 -0400 (EDT) Message-ID: <39728CC1.50E56359@dynamicsoft.com> Date: Mon, 17 Jul 2000 00:34:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: multipart/mixed; boundary="------------EC822218C66D2D4BFE860FBE" Subject: [SIP] [Fwd: I-D ACTION:draft-rosenberg-sip-hearingimpaired-00.txt] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. --------------EC822218C66D2D4BFE860FBE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------------EC822218C66D2D4BFE860FBE Content-Type: message/rfc822 Content-Disposition: inline Received: from wodc7mr3.ffx.ops.us.uu.net by wodc7ps1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) id QQixvf06310; Fri, 14 Jul 2000 16:47:02 GMT Received: from loki.ietf.org by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: loki.ietf.org [132.151.1.177]) id QQixvf09393; Fri, 14 Jul 2000 16:47:02 GMT Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id MAA14427 for ietf-123-outbound.02@ietf.org; Fri, 14 Jul 2000 12:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA10915 for ; Fri, 14 Jul 2000 06:55:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10322; Fri, 14 Jul 2000 06:55:35 -0400 (EDT) Message-Id: <200007141055.GAA10322@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: I-D ACTION:draft-rosenberg-sip-hearingimpaired-00.txt Date: Fri, 14 Jul 2000 06:55:35 -0400 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Enabled Services to Support the Hearing Impaired Author(s) : J. Rosenberg, H. Schulzrinne, H. Sinnreich Filename : draft-rosenberg-sip-hearingimpaired-00.txt Pages : 14 Date : 13-Jul-00 This document outlines a set of services enabled by the Session Initiation Protocol (SIP), that allow for access to voice services by people who are hearing impaired. SIP has gained much attention as a tool for voice communications on the Internet. Therefore, considerations for universal access of its services are important. This document does not propose any extensions or new capabilities to SIP, but rather a set of services enabled by it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hearingimpaired-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-hearingimpaired-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-hearingimpaired-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: <20000713145548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-hearingimpaired-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-hearingimpaired-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145548.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------EC822218C66D2D4BFE860FBE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 01:12:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17256 for ; Mon, 17 Jul 2000 01:12:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2CE754434E; Mon, 17 Jul 2000 01:12:27 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D30CE44336 for ; Mon, 17 Jul 2000 01:12:24 -0400 (EDT) Received: from dynamicsoft.com (1Cust91.tnt5.freehold.nj.da.uu.net [63.36.113.91]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01115; Mon, 17 Jul 2000 01:13:50 -0400 (EDT) Message-ID: <39729683.18005B00@dynamicsoft.com> Date: Mon, 17 Jul 2000 01:15:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fox, Mike" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] How many RTP streams? References: <613A6A6A3F09D3118F5C00508B2C24FEAD8AEB@sd_exchange.nuera.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Fox, Mike" wrote: > > Just how many 2833 RTP streams should a UAC support? In terms of "best > practices" should each SIP Application Server (SAS) taking part in a session > receive it's own 2833 stream from the UAC, or should each application server > forward the stream to the next inline SAS? Since each app server will not know about any others, in all likelihood, I don't see how any kind of cooperative process, like forwarding, could work. In fact, an app server wouldn't even be able to determine if a UAS is actually another app server or the final destination. Forwarding would allow for some > feature interaction reduction by deleting recognized events and not > forwarding them to down stream devices, of course this adds delay. This seems completely infeasible. How would one app server know what the next one wants to do? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 01:29:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25481 for ; Mon, 17 Jul 2000 01:29:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0483D44363; Mon, 17 Jul 2000 01:28:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 08D904434F for ; Mon, 17 Jul 2000 01:28:42 -0400 (EDT) Received: from dynamicsoft.com (1Cust91.tnt5.freehold.nj.da.uu.net [63.36.113.91]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01144; Mon, 17 Jul 2000 01:29:55 -0400 (EDT) Message-ID: <39729A47.7B247DC8@dynamicsoft.com> Date: Mon, 17 Jul 2000 01:31:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Girzon, Gary" Cc: "Culpepper, Bert" , Christian Huitema , sip@lists.bell-labs.com Subject: Re: [SIP] summary: DTMF and voice-over-packet References: <2CC2CB3C95C3D311ABAC009027DCD77E0AB9D0@wks194.pactolus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Girzon, Gary" wrote: > > I see a couple of problems with Jonathan's response - > > Does the RTP that comes into the Media Server have in-band audio > as well? If yes, then my Media Server has to know to throw it away, > If not, then the source of the RTP has to generate 2 distinct RTP streams > - one with audio (and maybe DTMF events), one with only DTMF events. > So while you don't need any DSP resources, you > most certainly need additional network processing resources on both ends... > > Most Media Server (and Media Gateway) hardware architectures today > split their ethernet pipes. There is typically one physical interface > for the controlling protocol (like MGCP/ Megaco or even XML) and one for the > > streaming media (like RTP). So even though everything eventually flows > through a single IP pipe, it makes sense to split the data since > the media bandwidth is significantly higher. Furthermore, the protocol port > is shared by all the media ports and is typically exposed only to another > SIP > server (ie., the Application Server). It does not have an RTP stack. > In this architecture, maintaining RTP connection in the MS ports creates > a significant overhead, as Bert has pointed out. And I am talking about > Media Gateways/Servers that must support thousands of ports of media. Presumably any media server you buy supports some kind of dtmf detection, speech recognition, or whatever. Presumably, there is some kind of control path that allows these media events to be reported to a control process somewhere in the media server. Using rfc2833 reuses all of that infrastructure, but you save a huge amount on DSP resources which you no longer need. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 01:37:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00339 for ; Mon, 17 Jul 2000 01:37:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6AF8644367; Mon, 17 Jul 2000 01:37:24 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4E2C144359 for ; Mon, 17 Jul 2000 01:37:21 -0400 (EDT) Received: from dynamicsoft.com (1Cust91.tnt5.freehold.nj.da.uu.net [63.36.113.91]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01157; Mon, 17 Jul 2000 01:38:25 -0400 (EDT) Message-ID: <39729C45.6CC80375@dynamicsoft.com> Date: Mon, 17 Jul 2000 01:40:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Arjun_Roychowdhury@hss.hns.com Cc: rafi , sip@lists.bell-labs.com Subject: Re: [SIP] How to detect interworking ? References: <6525691B.0045CA87.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Arjun_Roychowdhury@hss.hns.com wrote: > > Well, > we did do a similar thing in our SIP-323 GW - we added a proprietary token that > the signalling gateway would insert in one of the headers. > However, it would be nice if we all had one "well known" way of doing it. > Reason being that though the IWF box is a legit SIP UA on the SIP side, while > developing one, we often put in only basic features (we just did a call setup > and teardown) and dont want the end SIP UA to do more fancy stuff (like SIP call > transfer etc) assuming it was a SIP-SIP call . This is very, VERY bad. SIP already defines mechanisms that allow a UAC to determine what extensions, methods, body types, etc. are supported by the UAS (including whether it supports transfer). Defining another method to do that which identifies a "profile" of SIP with a single new header seems a slippery, dangerous road to take. Many people argued strongly about this during the sip-h.323 bof. > > Well, thats really an implementation ramble from this side, and our proprietary > extension worked fine since we had HSS UAs too... > > So rafi, we faced the same issue (if thats what we would like to call it) - > maybe some time down the line, when more people jump into > implementing a SIP-H.323 GW, putting some fixed token with a fixed value to > indicate a protcol X - SIP conversion would be nice. No, I think this would be a dreadful mistake. It is *fundamental* to the nature of this conversion that the SIP UA component be a true SIP UA. Having some kind of special extensions in there required to support it means its no longer interoperable with baseline SIP. IP phones, gateways, etc. would now all need to know about this special thing called a SIP-H.323 gateway, and adjust behavior accordingly. As we define more and more of such conversion boxes, it becomes a nightmare to manage this, and all interoperability will eventually go away. I fail to understand why this device is so special that it cannot use the normal SIP extensibility mechanisms. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 01:52:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08423 for ; Mon, 17 Jul 2000 01:52:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 257BA4436C; Mon, 17 Jul 2000 01:52:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id 62AF84434E for ; Mon, 17 Jul 2000 01:52:07 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id LAA04726 for ; Mon, 17 Jul 2000 11:21:51 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Mon, 17 Jul 2000 11:21:50 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id LAA27961 for ; Mon, 17 Jul 2000 11:21:44 +0530 (IST) Message-ID: <006701bfefb2$e75e5740$8c40000a@sasi.com> From: "rafi" To: Date: Mon, 17 Jul 2000 11:20:25 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01BFEFE1.00EBD9C0" 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] On Transcoding Device Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0064_01BFEFE1.00EBD9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In Draft "draft-camarillo-3pcc-qos-00.txt" in section 3, example is given where use of transcoding device is mentioned. This device act as a "dial-up bridge" and bridges two audio stream from UAC - T and T- UAS (where T is transcoding service agent ) and vice versa. However=20 it is not clear how T comes to know which of the two=20 audio stream it has to bridge. Thank You Rafi Assadi H.M Silicon Automation Systems Bangalore ------=_NextPart_000_0064_01BFEFE1.00EBD9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
 
        In=20 Draft  "draft-camarillo-3pcc-qos-00.txt"
in section 3, example is  given=20 where
use of transcoding device is mentioned. = This
device act as a "dial-up bridge" = and  bridges =20 two
audio stream from UAC - T and  T- = UAS (where=20 T
is transcoding service agent ) and vice = versa.=20 However
it is not clear=20 how T comes  to know which of = the  two=20
audio  stream=20 it has to  bridge.
 
 
Thank You
Rafi Assadi H.M
Silicon Automation Systems
Bangalore
 
 
------=_NextPart_000_0064_01BFEFE1.00EBD9C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 03:00:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03557 for ; Mon, 17 Jul 2000 03:00:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A83444363; Mon, 17 Jul 2000 03:00:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from condor-ext.wise.edt.ericsson.se (condor-ext.wise.edt.ericsson.se [194.237.142.114]) by lists.bell-labs.com (Postfix) with ESMTP id 218D64434E for ; Mon, 17 Jul 2000 03:00:25 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by condor.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6H70Nn03410; Mon, 17 Jul 2000 09:00:23 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.114]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA23791; Mon, 17 Jul 2000 09:49:41 +0300 (EET DST) Message-ID: <3972AC8A.46CDBB10@lmf.ericsson.se> Date: Mon, 17 Jul 2000 09:49:46 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rafi Cc: sip@lists.bell-labs.com Subject: Re: [SIP] On Transcoding Device References: <006701bfefb2$e75e5740$8c40000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, T receives two INVITEs, each one with an SDP. These two INVITEs can be matched betweeen them because they use the same URI in the Request-URI (in the example: session3371@transcoder.provider3.com). The trancoder has to bridge between the SDP of one INVITE and the SDP of the other one. That is, everything received on one side is sent to the other side and the other way around. Regards, Gonzalo > rafi wrote: > > Hi, > > > In Draft "draft-camarillo-3pcc-qos-00.txt" > in section 3, example is given where > use of transcoding device is mentioned. This > device act as a "dial-up bridge" and bridges two > audio stream from UAC - T and T- UAS (where T > is transcoding service agent ) and vice versa. However > it is not clear how T comes to know which of the two > audio stream it has to bridge. > > > Thank You > Rafi Assadi H.M > Silicon Automation Systems > Bangalore > > -- 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 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 03:18:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07390 for ; Mon, 17 Jul 2000 03:18:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D2FD44378; Mon, 17 Jul 2000 03:17:32 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2]) by lists.bell-labs.com (Postfix) with ESMTP id A2F9B4436E for ; Mon, 17 Jul 2000 03:17:25 -0400 (EDT) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id MAA08090 for ; Mon, 17 Jul 2000 12:47:02 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Mon, 17 Jul 2000 12:47:00 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id MAA29129 for ; Mon, 17 Jul 2000 12:46:55 +0530 (IST) Message-ID: <008001bfefbe$cd4a8160$8c40000a@sasi.com> From: "rafi" To: Date: Mon, 17 Jul 2000 12:45:35 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01BFEFEC.E6D803E0" 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] What is the max limit on the number of Translator ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_007D_01BFEFEC.E6D803E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Consider a call set up between a normal and hearing impaired user (hiu) (assuming hiu can=20 receive text and send speech only). In this case service of speech translator is made use of in the direction from caller (normal user) to hiu. Assuming=20 that there is no common codec between speech translator server and the caller, service of transcoding server is used.=20 Thus audio stream from the caller terminates at transcoding=20 server, from transcoding server it terminates at=20 speech translator server and finally from speech translator at hiu. Thus three RTP streams are bridged. Thus, is okay to have two or more intermediate translator in a given media path ?.=20 In general how many intermediate translator can be there ? Thank You Rafi Assadi H.M. ------=_NextPart_000_007D_01BFEFEC.E6D803E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
          &nbs= p;  =20 Consider a call set up between  a normal
    and hearing impaired = user (hiu) =20 (assuming hiu can
    receive text and = send speech only). In this case
    service of speech=20 translator is made use of in=20 the
    direction from = caller (normal=20 user) to hiu. Assuming
    that there is = no  common=20 codec between speech = translator
    server and  the = caller,=20 service of transcoding server  = is used.=20
    Thus audio stream from the caller terminates at transcoding =
    server, from = transcoding server=20 it terminates at
    speech translator = server and=20 finally from speech translator at
    hiu. Thus  three  RTP = streams are=20 bridged. Thus, is okay = to
    have two  or more intermediate translator in a given media path ?. =
    In = general how many  intermediate translator can be = there=20 ?
 
 
Thank You
Rafi Assadi H.M.
 
 
------=_NextPart_000_007D_01BFEFEC.E6D803E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 05:11:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05199 for ; Mon, 17 Jul 2000 05:11:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 403074434E; Mon, 17 Jul 2000 05:10:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from jodie.lucid (unknown [212.25.93.158]) by lists.bell-labs.com (Postfix) with SMTP id 66EAD44336 for ; Mon, 17 Jul 2000 05:10:25 -0400 (EDT) Received: (qmail 10067 invoked by uid 1002); 17 Jul 2000 09:00:54 -0000 From: Dvir Oren MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Jul 2000 12:00:52 +0300 (IDT) To: SIP X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14706.51604.253211.482750@jodie.lucid> Subject: [SIP] Local Calling Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit I've been trying to allow 'local calling' within my user agent, and ran into some difficulties. I was wondering if there is any internet draft or some kind of protcol to do this. By 'local calls' I mean a call in which the caller and callee share the same user agent client/server. This causes some difficulties, since the UAC and UAS share the same pool of call states. When the callee receives an INVITE, there would already be a call with those parameters since it was initiated from from the same place. At this point I see two scenarios: 1. The UAS added a tag to the 'to' field, however the UAC has sent another INVITE. When compared, the INVITEs will not match, and now the UAS will try to initiate a new call. 2. The UAS did not add a tag to the 'to' field, but when compared, it will already find the call that the caller initiated. Any ideas? -- Dvir Oren Lucid VON Ltd. 9 Saloniki St., Tel-Aviv Israel Tel: +972 3 644 3038 Fax: +972 3 644 3039 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 06: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 ESMTP id GAA25845 for ; Mon, 17 Jul 2000 06:42:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 810174434E; Mon, 17 Jul 2000 06:41:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 1D1C344336 for ; Mon, 17 Jul 2000 06:41:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25411; Mon, 17 Jul 2000 06:41:10 -0400 (EDT) Message-Id: <200007171041.GAA25411@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 17 Jul 2000 06:41:09 -0400 Subject: [SIP] I-D ACTION:draft-thernelius-sip-firewall-solution-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Firewall Solution Author(s) : F. Thernelius Filename : draft-thernelius-sip-firewall-solution-00.txt Pages : 16 Date : 14-Jul-00 This document describes a solution that is able to handle SIP signaling together with NAT enabled firewalls. The intent is to show that existing firewalls do not have to be replaced by 'SIP enabled' ones, instead they will only have to be reconfigured slightly. The main feature of this solution is using MGCP from a session control proxy to open/close holes in an RTP proxy which then enables RTP traffic to flow between interconnected networks. Worth noting is that this solution will not only work for SIP, it will also work for other protocols, such as H.323 or Real Audio. It does not even have to be RTP that is passed through the RTP proxy, though this draft assumes that the RTP stream is accompanied by RTCP. The solution will work for any protocol that wishes to open/close ports dynamically in the RTP proxy (maybe it should be called Forwarding Engine in the general case). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thernelius-sip-firewall-solution-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-thernelius-sip-firewall-solution-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-thernelius-sip-firewall-solution-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: <20000714143606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thernelius-sip-firewall-solution-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-thernelius-sip-firewall-solution-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143606.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 Jul 17 06:43:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26406 for ; Mon, 17 Jul 2000 06:43:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1F2F844365; Mon, 17 Jul 2000 06:42:21 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id DC4024435A for ; Mon, 17 Jul 2000 06:42:11 -0400 (EDT) Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA20399; Mon, 17 Jul 2000 11:39:20 +0100 (BST) From: "Jo Hornsby" To: "David Daiker" Cc: "Kim Liu" , Subject: RE: [SIP] Hide: header and record-route (was: A question about stateful proxies) Date: Mon, 17 Jul 2000 11:39:20 +0100 Message-ID: <000d01bfefdb$43abc4b0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <200007142033.QAA07085@blanc.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit > What should be the interaction of record-route and hide:hop/route ? There is no interaction, per se -- they are completely orthogonal. > Should a proxy remove the 'hide:' header it it's going to turn > on record-route ? > or should proxies encrypt the previous hop route if they're handling > requests and responses with privacy and a route header ? Proxies should obey the Hide headers as they would do if there were no [Record-]Route headers present, and vice-versa. I would note, however, that using Hide together with Record-Route is pretty-much oxymoronic. &:) > What were some of the comments at the bake-off ? As Johnathan pointed out, doing something akin to Hide, except with [Record-]Route is impossible. I must have been hallicunating, or something, and imagined it all (does the phrase "Cycling Bowler Caps" mean anything to anybody?) 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 Jul 17 06:44:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26982 for ; Mon, 17 Jul 2000 06:44:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 166C444385; Mon, 17 Jul 2000 06:42:46 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id A5CBE44362 for ; Mon, 17 Jul 2000 06:42:40 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26128; Mon, 17 Jul 2000 06:42:39 -0400 (EDT) Message-Id: <200007171042.GAA26128@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 17 Jul 2000 06:42:39 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-mib-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Management Information Base for Session Invitation Protocol Author(s) : K. Lingle, J. Maeng, D. Walker Filename : draft-ietf-sip-mib-01.txt Pages : 76 Date : 14-Jul-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol(SIP) [17] devices, which include User Agent, Proxy server, Redirect server and Registrar. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000714143946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143946.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 Jul 17 06: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 ESMTP id GAA27458 for ; Mon, 17 Jul 2000 06:46:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A22644393; Mon, 17 Jul 2000 06:42:52 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 502604437C for ; Mon, 17 Jul 2000 06:42:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26162; Mon, 17 Jul 2000 06:42:44 -0400 (EDT) Message-Id: <200007171042.GAA26162@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 17 Jul 2000 06:42:43 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-call-flows-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP 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-01.txt Pages : 192 Date : 14-Jul-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-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-call-flows-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-call-flows-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000714144000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-call-flows-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-call-flows-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714144000.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 Jul 17 06:47:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27834 for ; Mon, 17 Jul 2000 06:47:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44C5044353; Mon, 17 Jul 2000 06:42:59 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 77ABB4438D for ; Mon, 17 Jul 2000 06:42:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26200; Mon, 17 Jul 2000 06:42:48 -0400 (EDT) Message-Id: <200007171042.GAA26200@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 17 Jul 2000 06:42:47 -0400 Subject: [SIP] I-D ACTION:draft-ietf-sip-info-method-05.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP INFO Method Author(s) : S. Donovan Filename : draft-ietf-sip-info-method-05.txt Pages : 10 Date : 14-Jul-00 This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP and ISDN signaling messages used to control telephony call services. This and other example uses of the INFO method may be standardized in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-info-method-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-info-method-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-info-method-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000714144010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-info-method-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-info-method-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714144010.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 Jul 17 09:55:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17331 for ; Mon, 17 Jul 2000 09:55:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2679744351; Mon, 17 Jul 2000 09:55:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from blanc.cisco.com (blanc.cisco.com [161.44.3.203]) by lists.bell-labs.com (Postfix) with ESMTP id 044A744336 for ; Mon, 17 Jul 2000 09:54:59 -0400 (EDT) Received: (ddaiker@localhost) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id JAA08894; Mon, 17 Jul 2000 09:54:14 -0400 (EDT) From: David Daiker Message-Id: <200007171354.JAA08894@blanc.cisco.com> Subject: Re: [SIP] A question about Stateful Proxies, Session Timers, and the To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Mon, 17 Jul 2000 09:54:14 -0400 (EDT) Cc: jhornsby@ubiquity.net (Jo Hornsby), kliu@lucent.com (Kim Liu), sip@lists.bell-labs.com In-Reply-To: <3971C7AB.E36AF4C3@dynamicsoft.com> from "Jonathan Rosenberg" at Jul 16, 2000 10:33:15 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan, actually I think it *could* be done. Just like 'via' encryption, btw, with the exception that on responses the downstream route is encrypted, not popped. That way the caller sees only the 1st (record-route) downstream proxy in the clear, and the callee sees only the final one. david > Jo Hornsby wrote: > > > > > Out of curiosity, are there going to be options to allow for the > > > encryption of the Record-Route path the same where you can Hide > > > Via headers, so that if you are trying to hide the route taken by a > > > message across your internal network of stateful proxies you can? > > > > I'm not really in a position to comment on this &:), although do > > I dimly remember some discussion from the 4th Bake-Off? (I'm > > actually struggling to see how this could possibly work...although > > perhaps if UAC and UAS were presented with headers encrypted in > > the appropriate "direction"...Hmmm....) > > It just doesn't work. Unlike Via, where the encryption happens in one > direction (downstream), and decryption in the other (upstream), > Record-Route > results in the construction of Route headers that are used for > subsequent > requests from called UA to calling UA, *AND* calling UA to called UA. > This means > you can't encrypt either the Record-Route before or after your own... > > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 10:24:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00246 for ; Mon, 17 Jul 2000 10:24:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0EE174435D; Mon, 17 Jul 2000 10:23:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id 200F74434E for ; Mon, 17 Jul 2000 10:23:32 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nok.ntc.nokia.com [131.228.10.154]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6HENNx12306 for ; Mon, 17 Jul 2000 17:23:24 +0300 (EET DST) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 17 Jul 2000 17:07:41 +0300 Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id <3099AFFS>; Mon, 17 Jul 2000 17:07:41 +0300 Message-ID: <11CD408013B6D2119BB50008C7EA510C03A8D0F2@eseis05nok> From: Sapan.Bhatia@nokia.com To: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Tunneling with SIP Date: Mon, 17 Jul 2000 16:59:05 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com // "Fox, Mike" wrote: // > // > Jonathan Rosenberg wrote: // > > I would not advocate tunneling DHCP over SIP, HTTP over SIP, // > > or SLP over // > > SIP, since those protocols // > > don't do the same thing SIP does. Same with megaco/mgcp. // > > Tunneling them // > > over SIP serves no purpose. SIP is not a good transfer // > > protocol (see the // > > Guidelines for Authors of SIP Extensions: // > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-gui // > >delines-00.txt). // > >Just use the native transport define by the protocol. // > // > Perhaps it would be too simple an extrapolation to // conclude that you are not // > in favor of ... // > http://www.ietf.org/internet-drafts/draft-deason-sip-soap-00.txt // > // > Could you share your opinion? (I would mine, but few care // about it! ;-) // // I do not believe that SIP is a useful RPC mechanism. None // of its user // discovery and registration capabilities are needed for // RPC, neither // are most of its proxy functions. As it is not an ideal transfer // protocol, it is not good at carrying serialized objects // of any large // size. // // -Jonathan R. // Well, correct me if I'm wrong, but when you talk of ORPC over SIP, then the ORPC mechanism would be handled by another protocol (like SOAP-XML) which would encapsulate information such as Object ID's, Interface id's, context information etc. So the user-discovery/registration capabilities of SIP would not be required since object requests would not directly utilize the capabilities of SIP, but of SOAP which is transferred as SIP payload (just as it is in HTTP - <>). And also, the payload would typically be used to relay ORPC request-responses and not large serialized objects. -Sapan Bhatia _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 10:40:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06639 for ; Mon, 17 Jul 2000 10:40:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57C704436B; Mon, 17 Jul 2000 10:39:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sundns.transnexus.com (mail.transnexus.com [209.144.152.22]) by lists.bell-labs.com (Postfix) with ESMTP id 0DE6F44367 for ; Mon, 17 Jul 2000 10:39:15 -0400 (EDT) Received: from notebook.transnexus.com ([192.168.1.198]) by sundns.transnexus.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28406 for ; Mon, 17 Jul 2000 14:39:12 GMT Message-Id: <4.3.2.7.2.20000717103735.00b37da8@mail.transnexus.com> X-Sender: sthomas@mail.transnexus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 10:40:57 -0400 To: sip@lists.bell-labs.com From: Stephen Thomas In-Reply-To: <200007141055.GAA10171@ietf.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_8662135==_" Subject: [SIP] Re: I-D ACTION:draft-johnston-sip-osp-token-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --=====================_8662135==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Just a note that there is an additional I-D on this topic that (so far) hasn't made it out of the announcement queue. Since it's tiny, I've attached it here. Note that the two approaches are in no way mutually exclusive. The draft-thomas-sip-mime-osp-token-00.txt approach defines a MIME type rather than a SIP header. Stephen At 06:55 AM 2000-07-14, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : OSP Authorization Token Header for SIP > Author(s) : A. Johnston, D. Rawlins, H. Sinnreich > Filename : draft-johnston-sip-osp-token-00.txt > Pages : 5 > Date : 13-Jul-00 > >This draft proposes a new SIP (Session Initiation Protocol) header >OSP-Authorization-Token for carrying an OSP (Open Settlements >Protocol) authorization token between domains. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-token-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-johnston-sip-osp-token-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-johnston-sip-osp-token-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000713145458.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-johnston-sip-osp-token-00.txt > > --=====================_8662135==_ Content-Type: text/plain; name="draft-thomas-sip-mime-osp-token-00.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="draft-thomas-sip-mime-osp-token-00.txt" Content-Transfer-Encoding: base64 CgoKSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAgICAgICAgICAgICAgIFN0ZXBoZW4g VGhvbWFzLCBUcmFuc05leHVzCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEJ1dGNoIEFudG9uLCBoZXJlVWFyZQpkcmFmdC10aG9tYXMtc2lwLW1pbWUt b3NwLXRva2VuLTAwLnR4dCAgICAgICAgICAgICBSaWNoYXJkIEJyZW5uYW4sIEdSSUMKSnVseSAx NCwgMjAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERhdmlkIE9y YW4sIENpc2NvCkV4cGlyZXMgSmFudWFyeSAxNCwgMjAwMQoKICAgICAgICAgICAgICAgICAgVGhl IGFwcGxpY2F0aW9uL29zcC10b2tlbiBNSU1FIHR5cGUKClNUQVRVUyBPRiBUSElTIE1FTU8KCiAg IFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9y bWFuY2Ugd2l0aAogICBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuCgog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtp bmcgZ3JvdXBzLiBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4CiAgIG1v bnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzCiAgIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGFzIHdvcmsgaW4gcHJvZ3Jlc3MuCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRm LzFpZC1hYnN0cmFjdHMudHh0CgogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cg RGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwuCgoxLiBBYnN0cmFjdAoKICAgVGhlIE9wZW4gU2V0dGxlbWVudCBQcm90b2NvbCAo T1NQKVsxXSwgYW4gb3BlbiBzdGFuZGFyZCBmcm9tIHRoZQogICBFdXJvcGVhbiBUZWxlY29tbXVu aWNhdGlvbnMgU3RhbmRhcmRzIEluc3RpdHV0ZSwgc3BlY2lmaWVzIGEgbWVhbnMKICAgYnkgd2hp Y2ggSVAgdGVsZXBob255IGVxdWlwbWVudCBpbiBvbmUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIG1h eQogICByZXF1ZXN0IGFjY2VzcyB0byBJUCB0ZWxlcGhvbnkgZXF1aXBtZW50IChpbmNsdWRpbmcs IGJ1dCBub3QgbGltaXRlZAogICB0bzogR2F0ZXdheXMsIFByb3h5IFNlcnZlcnMsIEdhdGVrZWVw ZXJzLCBldGMuKSBpbiBhbm90aGVyCiAgIGFkbWluaXN0cmF0aXZlIGRvbWFpbi4gT1NQIGdyYW50 cyBzdWNoIGFjY2VzcyBieSByZXR1cm5pbmcKICAgYXV0aG9yaXphdGlvbiB0b2tlbnMsIHdoaWNo IG11c3QgdGhlbiBiZSBwYXNzZWQgdG8gdGhlIGRlc3RpbmF0aW9uCiAgIElQIHRlbGVwaG9ueSBk ZXZpY2UgZHVyaW5nIGNhbGwgc2lnbmFsaW5nLiBJbiBvcmRlciB0byBzdXBwb3J0CiAgIGFjY2Vz cyBjb250cm9sIHZpYSBPU1AsIElQIHRlbGVwaG9ueSBzaWduYWxpbmcgcHJvdG9jb2xzIG11c3Qg YmUKICAgY2FwYWJsZSBvZiBjYXJyeWluZyB0aGVzZSBhdXRob3JpemF0aW9uIHRva2VucyBpbiBh biBpbnRlcm9wZXJhYmxlCiAgIHdheS4gVGhpcyBtZW1vIGRlZmluZXMganVzdCBzdWNoIGEgbWV0 aG9kIGZvciBwcm90b2NvbHMsIHN1Y2ggYXMgdGhlCiAgIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90 b2NvbFsyXSwgdGhhdCBjYW4gc3VwcG9ydCBjYXJyaWFnZSBvZiBNSU1FCiAgIHR5cGVzIGR1cmlu ZyBjYWxsIHNpZ25hbGluZy4gVGhpcyBtZW1vIGNvbmZvcm1zIHRvIHRoZSByZXF1aXJlbWVudHMK ICAgZm9yIE1JTUUgdHlwZSByZWdpc3RyYXRpb24gZGVmaW5lZCBpbiBSRkMgMjA0OFszXS4KCjIu IFJlZ2lzdHJhdGlvbiBJbmZvcm1hdGlvbgoKICAgTUlNRSBtZWRpYSB0eXBlIG5hbWU6IGFwcGxp Y2F0aW9uCgoKVGhvbWFzLCBldCBhbCAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxNCwgMjAw MSAgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQgRHJhZnQgICAgICBUaGUgYXBw bGljYXRpb24vb3NwLXRva2VuIE1JTUUgdHlwZSAgICAgICAgICAgSnVseSAyMDAwCgoKCiAgIE1J TUUgc3VidHlwZSBuYW1lOiBvc3AtdG9rZW4KCiAgIFJlcXVpcmVkIHBhcmFtZXRlcnM6IG5vbmUg CgogICBPcHRpb25hbCBwYXJhbWV0ZXJzOiAKCiAgICAgIG9zcC10b2tlbi1mb3JtYXQ6IGEgdmFs dWUgb2YgImFzbi4xIiBpbmRpY2F0ZXMgdGhlIHRva2VuIGNvbnRlbnRzCiAgICAgICAgIHVzZSB0 aGUgQVNOLjEgZm9ybWF0IGRlZmluZWQgaW4gQW5uZXggRCwgc2VjdGlvbiBELjIuMSBvZiB0aGUg T1NQCiAgICAgICAgIHNwZWNpZmljYXRpb247IGEgdmFsdWUgb2YgInhtbCIgaW5kaWNhdGVzIHRo ZSB0b2tlbiBjb250ZW50cyB1c2UKICAgICAgICAgdGhlIFhNTCBmb3JtYXQgZGVmaW5lZCBpbiBB bm5leCBELCBzZWN0aW9uIEQuMi4yIG9mIHRoZSBPU1AKICAgICAgICAgc3BlY2lmaWNhdGlvbiwg YW5kIGEgdmFsdWUgb2YgImJ4bWwiIGluZGljYXRlcyB0aGUgdG9rZW4gY29udGVudHMKICAgICAg ICAgdXNlIHRoZSBCaW5hcnkgWE1MIGZvcm1hdCBkZWZpbmVkIGluIEFubmV4IEQsIHNlY3Rpb24g RC4yLjMgb2YgdGhlCiAgICAgICAgIE9TUCBzcGVjaWZpY2F0aW9uLiBJbiB0aGUgYWJzZW5jZSBv ZiBhbnkgdmFsdWUgZm9yIHRoaXMgcGFyYW1ldGVyLAogICAgICAgICB0aGUgdG9rZW4gY29udGVu dHMgc2hhbGwgYmUgc2VsZiBpZGVudGlmeWluZyBvciBvdGhlcndpc2UKICAgICAgICAgdW5kZXJz dG9vZCBieSBhcHByb3ByaWF0ZSBwYXJ0aWVzLgoKICAgICAgb3NwLXRva2VuLXZlcnNpb246IGEg Y2hhcmFjdGVyIHN0cmluZyBpbmRpY2F0aW5nIHRoZSBlYXJsaWVzdAogICAgICAgICByZXZpc2lv biBvZiB0aGUgT1NQIHNwZWNpZmljYXRpb24gdG8gd2hpY2ggdGhlIHRva2VuIGNvbnRlbnRzCiAg ICAgICAgIGNvbmZvcm0uIEluIHRoZSBhYnNlbmNlIG9mIGFueSB2YWx1ZSBmb3IgdGhpcyBwYXJh bWV0ZXIsIHRoZQogICAgICAgICB0b2tlbiBjb250ZW50cyBzaGFsbCBjb25mb3JtIHRvIHZlcnNp b24gIjIuMS4wIiBvZiB0aGUgT1NQCiAgICAgICAgIHNwZWNpZmljYXRpb24uCgogICBFbmNvZGlu ZyBjb25zaWRlcmF0aW9uczogT1NQIHRva2VucyBhcmUgbm9ybWFsbHkgY2FycmllZCBhcyBiaW5h cnkgZGF0YQogICAgICBieSB0aGUgY2FsbCBzaWduYWxpbmcgcHJvdG9jb2wuIENhbGwgc2lnbmFs aW5nIHByb3RvY29scyB3aGljaCBjYW5ub3QKICAgICAgcmVsaWFibHkgdHJhbnNmZXIgYmluYXJ5 IGRhdGEgbXVzdCB1c2UgYWx0ZXJuYXRlIGVuY29kaW5ncyBzdWNoIGFzCiAgICAgIGJhc2UtNjQs IGluIHdoaWNoIGNhc2Ugc3RhbmRhcmQgTUlNRSBjb250ZW50LWVuY29kaW5nIHBhcmFtZXRlcnMg bWF5CiAgICAgIGluZGljYXRlIHRoZSBwYXJ0aWN1bGFyIGVuY29kaW5nLgoKICAgU2VjdXJpdHkg Y29uc2lkZXJhdGlvbnM6IE9TUCB0b2tlbnMgYXJlIGludGVuZGVkIHRvIHByb3ZpZGUgYWNjZXNz CiAgICAgIGNvbnRyb2wgdG8gcmVzb3VyY2VzIG9mIG90aGVyIGFkbWluaXN0cmF0aXZlIGRvbWFp bnMsIGFuZCwgYXMgc3VjaCwKICAgICAgYXJlIGluaGVyZW50bHkgZGVzaWduZWQgdG8gYWRkcmVz cyBzZWN1cml0eSBjb25jZXJucy4gRm9yIHRoYXQKICAgICAgcmVhc29uLCBPU1AgdG9rZW5zIGFy ZSBkaWdpdGFsbHkgc2lnbmVkIGFuZCwgb3B0aW9uYWxseSwgZW5jcnlwdGVkLAogICAgICBhcyBk ZWZpbmVkIGluIHRoZSBPU1Agc3BlY2lmaWNhdGlvbi4KCiAgIEludGVyb3BlcmFiaWxpdHkgY29u c2lkZXJhdGlvbnM6IFRoZSBtZWFucyBhbmQvb3IgYWxnb3JpdGhtcyBieSB3aGljaAogICAgICBh IHJlY2VpdmluZyBzeXN0ZW0gZGV0ZXJtaW5lcyB3aGV0aGVyIG9yIG5vdCBhbiBPU1AgdG9rZW4g aXMgdmFsaWQKICAgICAgYXJlIGEgbG9jYWwgbWF0dGVyLiBIb3dldmVyLCBhdCBhIG1pbmltdW0s IHJlY2VpdmluZyBzeXN0ZW1zIHNob3VsZAogICAgICB2ZXJpZnkgdGhlIGRpZ2l0YWwgc2lnbmF0 dXJlIG9mIHRoZSB0b2tlbiwgYW5kIHRoZXkgc2hvdWxkIGVuc3VyZQogICAgICB0aGF0IGFueSBj YWxsIGRldGFpbHMgaW5jbHVkZWQgaW4gdGhlIHRva2VuIGNvbnRlbnRzIChlLmcuIGNhbGxlZAog ICAgICBudW1iZXIsIGNhbGxpbmcgbnVtYmVyLCBldGMuKSBhcmUgYXBwcm9wcmlhdGUgZm9yIHRo ZSBjb250ZW1wbGF0ZWQKICAgICAgY2FsbC4gCgogICBQdWJsaXNoZWQgc3BlY2lmaWNhdGlvbjog IlRlbGVjb21tdW5pY2F0aW9ucyBhbmQgSW50ZXJuZXQgUHJvdG9jb2wKICAgICAgSGFybW9uaXph dGlvbiBPdmVyIE5ldHdvcmtzIChUSVBIT04pOyBPcGVuIFNldHRsZW1lbnQgUHJvdG9jb2wgKE9T UCkKICAgICAgZm9yIEludGVyLWRvbWFpbiBwcmljaW5nLCBhdXRob3JpemF0aW9uLCBhbmQgdXNh Z2UgZXhjaGFuZ2UiLgogICAgICBUZWNobmljYWwgU3BlY2lmaWNhdGlvbiAxMDEgMzIxLiBFdXJv cGVhbiBUZWxlY29tbXVuaWNhdGlvbnMKICAgICAgU3RhbmRhcmRzIEluc3RpdHV0ZS4gVmVyc2lv biAyLjEuMC4KCgoKVGhvbWFzLCBldCBhbCAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxNCwg MjAwMSAgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQgRHJhZnQgICAgICBUaGUg YXBwbGljYXRpb24vb3NwLXRva2VuIE1JTUUgdHlwZSAgICAgICAgICAgSnVseSAyMDAwCgoKCiAg IEFwcGxpY2F0aW9ucyB3aGljaCB1c2UgdGhpcyBtZWRpYSB0eXBlOiBJUCB0ZWxlcGhvbnkgY2Fs bCBzaWduYWxpbmcKICAgICAgcHJvdG9jb2xzIHRoYXQgdXNlIE1JTUUgdHlwZXMgdG8gY29udmV5 IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gZHVyaW5nCiAgICAgIGNhbGwgc2V0dXAuCgogICBBZGRp dGlvbmFsIGluZm9ybWF0aW9uOiAKCiAgIE1hZ2ljIG51bWJlcihzKTogbm9uZSAKCiAgIEZpbGUg ZXh0ZW5zaW9uKHMpOiBub25lIAoKICAgTWFjaW50b3NoIEZpbGUgVHlwZSBDb2RlKHMpOiBub25l IAoKICAgUGVyc29uICYgZW1haWwgYWRkcmVzcyB0byBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9y bWF0aW9uOgogICAgICAgU3RlcGhlbiBUaG9tYXMsIHN0ZXBoZW4udGhvbWFzQHRyYW5zbmV4dXMu Y29tIAoKICAgSW50ZW5kZWQgdXNhZ2U6IENPTU1PTiAKCiAgIEF1dGhvci9DaGFuZ2UgY29udHJv bGxlcjogRXVyb3BlYW4gVGVsZWNvbW11bmljYXRpb25zIFN0YW5kYXJkcyBJbnN0aXR1dGUKCjMu IFJlZmVyZW5jZXMKCiAgIFsxXSBFdXJvcGVhbiBUZWxlY29tbXVuaWNhdGlvbnMgU3RhbmRhcmRz IEluc3RpdHV0ZS4gIlRlbGVjb21tdW5pY2F0aW9ucwogICAgICAgYW5kIEludGVybmV0IFByb3Rv Y29sIEhhcm1vbml6YXRpb24gT3ZlciBOZXR3b3JrcyAoVElQSE9OKTsgT3BlbgogICAgICAgU2V0 dGxlbWVudCBQcm90b2NvbCAoT1NQKSBmb3IgSW50ZXItZG9tYWluIHByaWNpbmcsIGF1dGhvcml6 YXRpb24sCiAgICAgICBhbmQgdXNhZ2UgZXhjaGFuZ2UiLiBUZWNobmljYWwgU3BlY2lmaWNhdGlv biAxMDEgMzIxLiBWZXJzaW9uIDIuMS4wLgoKICAgWzJdIE0uIEhhbmRsZXksIEguIFNjaHVsenJp bm5lLCBFLiBTY2hvb2xlciwgYW5kIEouIFJvc2VuYmVyZy4gIlNJUDoKICAgICAgIFNlc3Npb24g SW5pdGlhdGlvbiBQcm90b2NvbCIuIFJGQyAyNTQzLCBNYXJjaCAxOTk5LgoKICAgWzNdIE4uIEZy ZWVkLCBKLiBLbGVuc2luLCBhbmQgSi4gUG9zdGVsLiAiTXVsdGlwdXJwb3NlIEludGVybmV0IE1h aWwKICAgICAgIEV4dGVuc2lvbnMgKE1JTUUpIFBhcnQgRm91cjogUmVnaXN0cmF0aW9uIFByb2Nl ZHVyZXMiLiBSRkMgMjA0OCwKICAgICAgIE5vdmVtYmVyIDE5OTYuCgo0LiBBdXRob3JzJyBBZGRy ZXNzZXMKCiAgIEZvciBtb3JlIGluZm9ybWF0aW9uLCB0aGUgYXV0aG9ycyBvZiB0aGlzIGRvY3Vt ZW50IGFyZSBiZXN0CiAgIGNvbnRhY3RlZCB2aWEgSW50ZXJuZXQgbWFpbDoKCiAgIFN0ZXBoZW4g VGhvbWFzCiAgIFRyYW5zTmV4dXMKICAgNDMwIFRlbnRoIFN0cmVldCBOVywgU3VpdGUgTjIwNAog ICBBdGxhbnRhLCBHQSAzMDMxOAogICBVU0EKCiAgIFBob25lOiArMSA0MDQgODcyIDQ4ODcKICAg RmF4OiAgICsxIDQwNCA4NzIgOTUxNQogICBFTWFpbDogc3RlcGhlbi50aG9tYXNAdHJhbnNuZXh1 cy5jb20KCgoKVGhvbWFzLCBldCBhbCAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxNCwgMjAw MSAgICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQgRHJhZnQgICAgICBUaGUgYXBw bGljYXRpb24vb3NwLXRva2VuIE1JTUUgdHlwZSAgICAgICAgICAgSnVseSAyMDAwCgoKCiAgIEJ1 dGNoIEFudG9uCiAgIGhlcmVVYXJlIENvbW11bmljYXRpb25zLCBJbmMuCiAgIDM3MDcgV2lsbGlh bXMgUm9hZCwgU3VpdGUgMTAwCiAgIFNhbiBKb3NlLCBDQSA5NTExNwogICBVU0EKCiAgIFBob25l OiArMSA0MDggNTUxIDA5MDkKICAgRmF4OiAgICsxIDQwOCA5ODUgMDg5NQogICBFTWFpbDogYnV0 Y2hAaGVyZXVhcmUuY29tCgoKICAgUmljaGFyZCBCcmVubmFuCiAgIEdSSUMgQ29tbXVuaWNhdGlv bnMgSW5jLgogICAxNDIxIE1jQ2FydGh5IEJsdmQKICAgTWlscGl0YXMsIENBIDk1MDM1CiAgIFVT QQoKICAgUGhvbmU6ICsxIDQwOCA5NjUgMTE5MwogICBGYXg6ICAgKzEgNDA4IDk1NSAxOTY3CiAg IEVNYWlsOiByYnJlbm5hbkBncmljLmNvbQoKCiAgIERhdmlkIE9yYW4KICAgQ2lzY28gU3lzdGVt cywgSW5jLgogICA3IExhZHlzbGlwcGVyIExhbmUKICAgQWN0b24sIE1BIDAxNzIwCiAgIFVTQQoK ICAgUGhvbmU6ICsxIDUwOCAyNjQgMjA0OAogICBFTWFpbDogb3JhbkBjaXNjby5jb20KCgoKCgoK CgoKCgoKCgoKCgoKCgpUaG9tYXMsIGV0IGFsICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDE0 LCAyMDAxICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KCg== --=====================_8662135==_ Content-Type: text/plain; charset="us-ascii"; format=flowed ____________________________________________________________________ Stephen Thomas +1 404 872 4887 TransNexus, Chief Technical Officer stephen.thomas@transnexus.com --=====================_8662135==_-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 10:43:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07953 for ; Mon, 17 Jul 2000 10:43:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 231C744381; Mon, 17 Jul 2000 10:42:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id 2B54044378 for ; Mon, 17 Jul 2000 10:42:06 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0FXU00K01JI4JN@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 17 Jul 2000 14:42:04 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FXU00J3JJI4FJ@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 17 Jul 2000 14:42:04 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0FXU00001JF8MA@pmismtp03.wcomnet.com> for sip@lists.bell-labs.com; Mon, 17 Jul 2000 14:40:20 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FXU00001JEZKP@pmismtp03.wcomnet.com> for sip@lists.bell-labs.com; Mon, 17 Jul 2000 14:40:20 +0000 (GMT) Received: from omta3.mcit.com ([166.37.204.5]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FXU00HLOJEOO9@pmismtp03.wcomnet.com> for sip@lists.bell-labs.com; Mon, 17 Jul 2000 14:40:01 +0000 (GMT) Received: from wcom.com ([166.33.132.107]) by omta3.mcit.com (InterMail v03.02.07.05 118-131) with ESMTP id <20000717144212.GCWL25057@wcom.com> for ; Mon, 17 Jul 2000 14:42:12 +0000 Date: Mon, 17 Jul 2000 09:42:24 -0500 From: Alan Johnston Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-call-flows-01.txt To: sip@lists.bell-labs.com Message-id: <39731B4F.F086B439@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: <200007171042.GAA26162@ietf.org> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit The major changes between this draft and the previous draft are listed below: - SIP Telephony Service Examples have been removed from the draft. They will be revised using the TRANSFER header in a separate draft. - Updated draft with RFC2543bis changes including: adding maddr to all Record-Route and Route headers, adding branch tags to Via headers inserted by proxies, added 487 response to CANCEL scenarios. - Added example of INFO method in 5.1.1. - Added Session: media to all 183 messages. - Corrected a number of typos including putting user=phone tags inside <>, fixing Request-URI on PRACK, added missing tags, fixed Request-URIs that did not match To header in initial INVITE. - Corrected all registrations to have same Call-ID. As always, comments and corrections are always appreciated. Thanks, Alan Johnston WorldCom Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > Title : SIP Telephony Call Flow Examples > Author(s) : A. Johnston, S. Donovan, R. Sparks, > C. Cunningham, D. Willis, J. Rosenberg, > K. Summers, H. Schulzrinne > Filename : draft-ietf-sip-call-flows-01.txt > Pages : 192 > Date : 14-Jul-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-01.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-call-flows-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-call-flows-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. > > ------------------------------------------------------------------------ > > draft-ietf-sip-call-flows-01.txtName: draft-ietf-sip-call-flows-01.txt > Type: Plain Text (text/plain) _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 11:01:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16827 for ; Mon, 17 Jul 2000 11:01:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1093D44399; Mon, 17 Jul 2000 11:01:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by lists.bell-labs.com (Postfix) with ESMTP id 08FC144336 for ; Mon, 17 Jul 2000 11:01:02 -0400 (EDT) Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id LAA06140; Mon, 17 Jul 2000 11:01:23 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id UAA28126; Mon, 17 Jul 2000 20:00:58 +0500 Message-Id: <200007171500.UAA28126@hafez.east.isi.edu> To: Henning Schulzrinne Cc: sip@lists.bell-labs.com, rem-conf@es.net In-Reply-To: Your message of "Sat, 15 Jul 2000 15:24:31 EDT." <3970BA6F.F122BF5F@cs.columbia.edu> Date: Mon, 17 Jul 2000 11:00:58 -0400 From: Colin Perkins Subject: [SIP] Re: RFC 2833 ("tones") implementations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --> Henning Schulzrinne writes: >I would appreciate if implementors of RFC 2833 ("tones over RTP") could >get in touch with me. I'd like to start identifying implementations and >what features are used. > >Also, if anybody wants to support (or is already implementing) RTP >(e.g., RFC 2833) over TCP, please let me know. And whilst you're doing this, please review the drafts discussing RTP interoperability requirements (draft-ietf-avt-rtp-interop-03.txt and draft-ietf-avt-profile-interop-01.txt), and send me a brief report on your implementtion, so we can advance RTP to draft standard. Thanks! Colin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 12:44:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25838 for ; Mon, 17 Jul 2000 12:44:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A24844369; Mon, 17 Jul 2000 12:43:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id E4FBC4434C for ; Mon, 17 Jul 2000 12:43:03 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TLQ60>; Mon, 17 Jul 2000 09:42:46 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8B33@sd_exchange.nuera.com> From: "Fox, Mike" To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] How many RTP streams? Date: Mon, 17 Jul 2000 09:42:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com > From: Jonathan Rosenberg > "Fox, Mike" wrote: > > > > Just how many 2833 RTP streams should a UAC support? In > terms of "best > > practices" should each SIP Application Server (SAS) taking > part in a session > > receive it's own 2833 stream from the UAC, or should each > application server > > forward the stream to the next inline SAS? > > Since each app server will not know about any others, in all > likelihood, > I don't see how any kind of cooperative process, like > forwarding, could > work. In fact, an app server wouldn't even be able to > determine if a UAS > is actually another app server or the final destination. > Please forgive me, as I may be violating some small (or large) print in the spec... Could an app server ( lets call it A ) initially establish a ID2833 RTP stream from the UAC? Could the next hop from A, say it is a UAS, ask for a ID2833 RTP stream in an INVITE (or ACK), and wouldn't that INVITE cross A? Could A, knowing that it had access the ID2833 RTP stream for this session somehow forward the ID2833 RTP it is receiving to the UAS and condition the INVITE and its response to make things work, instead of allowing the SDP to go all the way down to the UAC and forking another ID2833 RTP from the UAC? > > Forwarding would allow for some > > feature interaction reduction by deleting recognized events and not > > forwarding them to down stream devices, of course this adds delay. > > This seems completely infeasible. How would one app server > know what the > next one wants to do? > > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 12:56:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29290 for ; Mon, 17 Jul 2000 12:56:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 772D64436C; Mon, 17 Jul 2000 12:56:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 5CCC04434C for ; Mon, 17 Jul 2000 12:56:00 -0400 (EDT) Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <3T6TLQ7D>; Mon, 17 Jul 2000 09:55:47 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8B34@sd_exchange.nuera.com> From: "Fox, Mike" To: sip@lists.bell-labs.com Date: Mon, 17 Jul 2000 09:55:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] How to stop a Lawnmower Man attack? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com In this attack scenario, a SIP zombie machine is established with access to necessary credentials for call initiation. This single machine then attempts call initiation with many endpoints. The resulting media streams could be used in an DOS attack against a given target or randomly interconnected as calls are answered as a prank. I do not see where in the current SIP architecture this type of threat is addressed. In the H.323 architecture an administrator could use the Zone and Gatekeeper approach to control the pattern of call initiation and acceptance. How is it to be done with SIP? Best regards, Mike Fox _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 13: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 ESMTP id NAA01603 for ; Mon, 17 Jul 2000 13:02:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C7DD544390; Mon, 17 Jul 2000 13:01:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 3715E44383 for ; Mon, 17 Jul 2000 13:01:09 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA21105; Mon, 17 Jul 2000 13:00:51 -0400 (EDT) Message-ID: <39733BC3.FBC53234@cisco.com> Date: Mon, 17 Jul 2000 13:00:51 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Usage of DNS SRV query Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com Content-Transfer-Encoding: 7bit A proxy can route a request using different mechanisms like : (a) Route header in incoming request (b) Contact headers obtained from REGISTER messages (c) Contact headers obtained from 3xx response (d) Outgoing Request-URI is same as incoming Request-URI ( it got a call for a foreign domain or host portion of incoming Request-URI is not the proxy) and there may be/are others. Should a proxy use the DNS SRV query for all the above cases. I guess, SRV query should not be used if proxy has some static routes or information that it uses for call routing. Comments ?? -- Best regards, Shail _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Jul 17 13:25:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10797 for ; Mon, 17 Jul 2000 13:25:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF5A144364; Mon, 17 Jul 2000 13:25:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uzura.cisco.com (uzura.cisco.com [161.44.3.77]) by lists.bell-labs.com (Postfix) with ESMTP id C013E4434C for ; Mon, 17 Jul 2000 13:25:11 -0400 (EDT) Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by uzura.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA23786 for ; Mon, 17 Jul 2000 13:24:30 -0400 (EDT) Message-ID: <39734166.440F6C0E@cisco.com> Date: Mon, 17 Jul 2000 13:24:54 -0400 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="------------60A3847896E05AC3D73CE898" Subject: [SIP] Handling 3xx after 1xx with SDP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SIP Mailing List X-BeenThere: sip@lists.bell-labs.com --------------60A3847896E05AC3D73CE898 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, How should SIP handle a 3xx response if it is received after a 1xx with SDP . A 1xx with SDP leads to bridging of a call and so if a 3xx is received after a call is bridged, we can pretty much do nothing at the SIP level . Cases where a 3xx is received after 1xx with no SDP has no problems. Is this true ? Your comments will be appreciated Thanks Ameet --------------60A3847896E05AC3D73CE898 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,

How should SIP handle a 3xx response if it is received after a 1xx with SDP .
A 1xx with SDP leads to bridging of a call and so if a 3xx is received after a call is bridged, we can pretty
much do nothing at the SIP level .  Cases where a 3xx is received after 1xx with no SDP has no problems.

Is this true ?

Your comments will be appreciated

Thanks
Ameet
  


 

--------------60A3847896E05AC3D73CE898--



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


From sip-admin@lists.bell-labs.com  Mon Jul 17 13:48:17 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21639
	for ; Mon, 17 Jul 2000 13:48:16 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B832A4438F; Mon, 17 Jul 2000 13:47:31 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 1AB144434C
	for ; Mon, 17 Jul 2000 13:47:28 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6HHlRM15335;
	Mon, 17 Jul 2000 19:47:27 +0200 (MEST)
Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id UAA23534;
	Mon, 17 Jul 2000 20:47:26 +0300 (EET DST)
Received: from lmf.ericsson.se (E005004B52C74-udp352065.lmf.ericsson.se [131.160.106.10])
	by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id UAA07795;
	Mon, 17 Jul 2000 20:47:24 +0300 (EETDST)
Message-ID: <39734660.5BFBA8E@lmf.ericsson.se>
Date: Mon, 17 Jul 2000 20:46:08 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: akher@cisco.com
Subject: Re: [SIP] Handling 3xx after 1xx with SDP
References: <39734166.440F6C0E@cisco.com>
Content-Type: multipart/mixed;
 boundary="------------43CD2F538975ED0901BC3D0D"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

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


Hi,

On an application level, to me it seems like a similar case when we
receive a re-INVITE, with new SDP parameters, during i session. In that
case we either modify whatever media stream we may have created, or
refuse to accept the re-INVITE. However, on a SIP level, in your example
it's not that simple. I guess we would have to send an ACK, and then a
BYE (or v.v. perhaps?) if we choose not to accept the new SDP
parameters.

Comments? Interesting case... :)

Christer Holmberg
Ericsson Finland




Ameet Kher wrote:
> 
> Hi All,
> 
> How should SIP handle a 3xx response if it is received after a 1xx
> with SDP .
> A 1xx with SDP leads to bridging of a call and so if a 3xx is received
> after a call is bridged, we can pretty
> much do nothing at the SIP level .  Cases where a 3xx is received
> after 1xx with no SDP has no problems.
> 
> Is this true ?
> 
> Your comments will be appreciated
> 
> Thanks
> Ameet
> 
> 
>
--------------43CD2F538975ED0901BC3D0D
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
fn:Christer Holmberg
end:vcard

--------------43CD2F538975ED0901BC3D0D--



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


From sip-admin@lists.bell-labs.com  Mon Jul 17 13:58:36 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26123
	for ; Mon, 17 Jul 2000 13:58:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0630444381; Mon, 17 Jul 2000 13:58:24 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 477AA44374
	for ; Mon, 17 Jul 2000 13:58:20 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA04430;
	Mon, 17 Jul 2000 13:59:41 -0400 (EDT)
Message-ID: <39734A02.9C3963F0@dynamicsoft.com>
Date: Mon, 17 Jul 2000 14:01:38 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fox, Mike" 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] How to stop a Lawnmower Man attack?
References: <613A6A6A3F09D3118F5C00508B2C24FEAD8B34@sd_exchange.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Fox, Mike" wrote:
> 
> In this attack scenario, a SIP zombie machine is established with access to
> necessary credentials for call initiation. This single machine then attempts
> call initiation with many endpoints. The resulting media streams could be
> used in an DOS attack against a given target or randomly interconnected as
> calls are answered as a prank.
> 
> I do not see where in the current SIP architecture this type of threat is
> addressed. In the H.323 architecture an administrator could use the Zone and
> Gatekeeper approach to control the pattern of call initiation and
> acceptance. How is it to be done with SIP?

Well, if I'm launching an attack with my zombie machine, its unlikely
I'll obey the GK message which tells me I can't make the call (I presume
you mean ARQ). You can also bypass the gatekeeper completely and send
call setup requests directly to clients. 

The real way to protect against this threat is with authentication in
the UAS. If you only accept calls from authenticated callers, even if
you don't know the person, you have a record of who launched the attack
that can be used to prosecute them later. 

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Mon Jul 17 14:19:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04593
	for ; Mon, 17 Jul 2000 14:19:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5AEAF44390; Mon, 17 Jul 2000 14:18:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 4FFB34434C
	for ; Mon, 17 Jul 2000 14:18:33 -0400 (EDT)
Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T6TLQ8W>; Mon, 17 Jul 2000 11:18:20 -0700
Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8B44@sd_exchange.nuera.com>
From: "Fox, Mike" 
To: Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] How to stop a Lawnmower Man attack?
Date: Mon, 17 Jul 2000 11:18:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

The zombie never belongs to the attacker it belongs to some other
unsuspecting dupe so is can be very hard (impossible?) to find who to
prosecute later. 

Not that it has been widely implemented, a GK can be used in conjunction
with a firewall so that only GK routed calls can be originated or accepted
by a Zone. The administrative problem of protecting a few GKs and a Firewall
seems more tractable than protecting all possible terminals. 

Mike

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, July 17, 2000 11:02 AM
> To: Fox, Mike
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] How to stop a Lawnmower Man attack?
> 
> 
> 
> 
> "Fox, Mike" wrote:
> > 
> > In this attack scenario, a SIP zombie machine is 
> established with access to
> > necessary credentials for call initiation. This single 
> machine then attempts
> > call initiation with many endpoints. The resulting media 
> streams could be
> > used in an DOS attack against a given target or randomly 
> interconnected as
> > calls are answered as a prank.
> > 
> > I do not see where in the current SIP architecture this 
> type of threat is
> > addressed. In the H.323 architecture an administrator could 
> use the Zone and
> > Gatekeeper approach to control the pattern of call initiation and
> > acceptance. How is it to be done with SIP?
> 
> Well, if I'm launching an attack with my zombie machine, its unlikely
> I'll obey the GK message which tells me I can't make the call 
> (I presume
> you mean ARQ). You can also bypass the gatekeeper completely and send
> call setup requests directly to clients. 
> 
> The real way to protect against this threat is with authentication in
> the UAS. If you only accept calls from authenticated callers, even if
> you don't know the person, you have a record of who launched 
> the attack
> that can be used to prosecute them later. 
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


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


From sip-admin@lists.bell-labs.com  Mon Jul 17 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 ESMTP id OAA17552
	for ; Mon, 17 Jul 2000 14:50:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 565DA44390; Mon, 17 Jul 2000 14:49:54 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id DC4B74434C
	for ; Mon, 17 Jul 2000 14:49:50 -0400 (EDT)
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 NAA02865;
	Mon, 17 Jul 2000 13:49:48 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA21278;
	Mon, 17 Jul 2000 13:49:48 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA19907; Mon, 17 Jul 2000 13:49:31 -0500 (CDT)
From: Sean Olson 
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id NAA06231;
	Mon, 17 Jul 2000 13:49:30 -0500 (CDT)
Date: Mon, 17 Jul 2000 13:49:30 -0500 (CDT)
Message-Id: <200007171849.NAA06231@b04a45.exu.ericsson.se>
To: sip@lists.bell-labs.com, akher@cisco.com
Subject: Re: [SIP] Handling 3xx after 1xx with SDP
X-Sun-Charset: US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


> Hi All,
> 
> How should SIP handle a 3xx response if it is received after a 1xx with
> SDP .
> A 1xx with SDP leads to bridging of a call and so if a 3xx is received
> after a call is bridged, we can pretty
> much do nothing at the SIP level .  Cases where a 3xx is received after
> 1xx with no SDP has no problems.
> 
> Is this true ?
> Your comments will be appreciated
> 
> Thanks
> Ameet

I don't see a problem in either situation (a 1xx with or without SDP).
The SDP in the 1xx response specifies (potentially) temporary media 
associated with the provisional response (such as remote ring tone). 
When a final response (2xx, 3xx, etc.) is received this media may be
torn down and replaced with media specified with SDP in the final response.
For a 3xx class response, I would tear down the media established with the
1xx response, then issue a new INVITE to the party or parties indicated in
the 3xx response (and consequently establish a new media connection).

This is similar to but not identical to a re-INVITE with new SDP.
I believe this is spelled out in more detail in the 183 draft.

cheers!
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  Mon Jul 17 14:51:26 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18071
	for ; Mon, 17 Jul 2000 14:51:26 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0ED35443A3; Mon, 17 Jul 2000 14:51:24 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 2136444349
	for ; Mon, 17 Jul 2000 14:51:20 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18001;
	Mon, 17 Jul 2000 14:51:13 -0400 (EDT)
Message-Id: <200007171851.OAA18001@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Date: Mon, 17 Jul 2000 14:51:12 -0400
Subject: [SIP] I-D ACTION:draft-ietf-sip-mib-01.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Management Information Base for Session Initiation 
                          Protocol
	Author(s)	: K. Lingle, J. Maeng, D. Walker
	Filename	: draft-ietf-sip-mib-01.txt
	Pages		: 76
	Date		: 14-Jul-00
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used
to manage Session Initiation Protocol(SIP) [17] devices, which
include User Agent, Proxy server, Redirect server and Registrar.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-01.txt

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

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-mib-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-mib-01.txt

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

Content-Type: text/plain
Content-ID:	<20000714143946.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 Jul 17 15:02:29 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22316
	for ; Mon, 17 Jul 2000 15:02:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 858AD443A9; Mon, 17 Jul 2000 15:01:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38])
	by lists.bell-labs.com (Postfix) with ESMTP id 96F944434C
	for ; Mon, 17 Jul 2000 15:01:06 -0400 (EDT)
Received: from krobohm.mci.net ([166.60.4.238])
 by shoe.reston.mci.net (PMDF V5.2-32 #40475)
 with ESMTPA id <01JRVM2JMBVS9N447R@shoe.reston.mci.net> for
 sip@lists.bell-labs.com; Mon, 17 Jul 2000 15:01:04 EST
Date: Mon, 17 Jul 2000 15:01:12 -0400
From: Kurt Robohm 
In-reply-to: <396E427E.B915975@ss8networks.com>
X-Sender: krobohm@shoe.reston.mci.net
To: sip-mib@egroups.com, SIP MIB Mailing List ,
        SIP Mailing List 
Cc: wjl@mci.net
Message-id: <4.3.2.7.2.20000717144438.00c98b70@shoe.reston.mci.net>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Content-type: multipart/alternative;
 boundary="Boundary_(ID_tzIBKNt32+IHkrBTqKdO+A)"
Subject: [SIP] Re: [sip-mib] revised SIP MIB draft
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


--Boundary_(ID_tzIBKNt32+IHkrBTqKdO+A)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-Transfer-Encoding: 7BIT

All,
I had reviewed a previous edition of the SIP MIB and logged a number of 
inquiries as indicated below.  A good deal of the objects I had questions 
or comments about now appear to not be present in the latest edition.  I 
searched through the email distro discussions and found no mention of 
having deleted these objects, so I'm a bit confused.  Anyway, if anyone 
would like to enlighten me a bit regarding my comments below, I'd 
appreciate it.

Kurt Robohm
Worldcom
Ashburn Virginia

Object NameInquiry
sipOrganizationWhere does the organization information originate from?
sipSummaryInRequestsHow about similar object for rejected request or 
responses?
sipStatsAckInsHow about similar object for a Nak?
sipStatsInfoTryingOutsIntent of object was to show number of transactions 
necessary to complete a call?
sipStatInfoRingingInsIntent of object was to show number of devices 
involved in the call route?
sipStatsClientBadRequestInsWill objects be indexed for every client?
sipStatsClientBadRequestInsIs there a client name object?
sipStatsClientBadRequestInsWill counter be incremented for packets that are 
bad/incomplete?
sipStatsClientBadRequestInsIs there a client IP address object?
sipStatsClientReqTimeoutInsWould lost packets be reason for timeout- or is 
this counted after a "trying" response is rx?
sipStatsClientLoopDetectedInsIs this equivalent to an echo on the line in 
older telephony parlance?
sipStatsServerGatewayTimeoutIns
sipCurrentTransacationsDoes this reflect number of calls in progress?
sipTransactionTableIntent of objects in table to provide real time info on 
number of calls being handled real time?
sipTransCallingPartyContentTypeIntent of object was to provide details on 
calls in progress?
SIP retry statisticsDo retries indicate any general network problems?
sipRxProxyAuthPasswordWhy is this object needed?  (seems like a security 
issue)



At 06:28 PM 7/13/00, Dave Walker wrote:
>Dear All,
>
>We have completed another revision of the SIP MIB and sent it to the IETF.
>
>To bypass the backlog, you can access it at
>http://www.ss8networks.com/files/internet-drafts/draft-ietf-sip-mib-01.txt
>
>Regards,
>
>Dave Walker
>SS8 Networks
>Ottawa, Canada
>
>------------------------------------------------------------------------
>To email plain text is conventional, to add graphics is divine.
>We'll show you how at www.supersig.com.
>http://click.egroups.com/1/6811/7/_/361123/_/963530241/
>------------------------------------------------------------------------
>
>To Post a message, send it to:   sip-mib@eGroups.com
>To Unsubscribe, send a blank message to: sip-mib-unsubscribe@eGroups.com

--Boundary_(ID_tzIBKNt32+IHkrBTqKdO+A)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7BIT


All,

I had reviewed a previous edition of the SIP MIB and logged a number of
inquiries as indicated below.  A good deal of the objects I had
questions or comments about now appear to not be present in the latest
edition.  I searched through the email distro discussions and found
no mention of having deleted these objects, so I'm a bit confused. 
Anyway, if anyone would like to enlighten me a bit regarding my comments
below, I'd appreciate it.



Kurt Robohm

Worldcom

Ashburn Virginia






Object
NameInquiry


sipOrganizationWhere
does the organization information originate from?


sipSummaryInRequestsHow about similar
object for rejected request or responses?


sipStatsAckInsHow about similar object
for a Nak?


sipStatsInfoTryingOutsIntent of object
was to show number of transactions necessary to complete a
call?


sipStatInfoRingingInsIntent of object was
to show number of devices involved in the call route?


sipStatsClientBadRequestInsWill objects
be indexed for every client? 


sipStatsClientBadRequestInsIs there a
client name object?


sipStatsClientBadRequestInsWill counter
be incremented for packets that are bad/incomplete?


sipStatsClientBadRequestInsIs there a
client IP address object?


sipStatsClientReqTimeoutInsWould lost
packets be reason for timeout- or is this counted after a
"trying" response is rx?


sipStatsClientLoopDetectedInsIs this
equivalent to an echo on the line in older telephony 
parlance?


sipStatsServerGatewayTimeoutIns


sipCurrentTransacationsDoes this reflect
number of calls in progress?


sipTransactionTableIntent of objects in
table to provide real time info on number of calls being handled real
time?






sipTransCallingPartyContentTypeIntent of
object was to provide details on calls in progress?


SIP retry statisticsDo retries indicate
any general network problems?


sipRxProxyAuthPasswordWhy is this object
needed?  (seems like a security issue)











At 06:28 PM 7/13/00, Dave Walker wrote:


Dear All,



We have completed another revision of the SIP MIB and sent it to the
IETF.  



To bypass the backlog, you can access it at

http://www.ss8networks.com/files/internet-drafts/draft-ietf-sip-mib-01.txt



Regards,



Dave Walker

SS8 Networks

Ottawa, Canada



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

To email plain text is conventional, to add graphics is divine. 


We'll show you how at
www.supersig.com.

http://click.egroups.com/1/6811/7/_/361123/_/963530241/

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



To Post a message, send it to:   sip-mib@eGroups.com

To Unsubscribe, send a blank message to:
sip-mib-unsubscribe@eGroups.com


--Boundary_(ID_tzIBKNt32+IHkrBTqKdO+A)--


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


From sip-admin@lists.bell-labs.com  Mon Jul 17 16:52:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02529
	for ; Mon, 17 Jul 2000 16:52:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A44FA4439C; Mon, 17 Jul 2000 16:52:06 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id B1B0444349
	for ; Mon, 17 Jul 2000 16:52:01 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon Jul 17 16:50:33 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 9D1BF4435D; Mon, 17 Jul 2000 16:37:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id 5884E44347
	for ; Mon, 17 Jul 2000 16:37:23 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id PAA23980; Mon, 17 Jul 2000 15:37:18 -0500
To: Henning Schulzrinne , SIP@lists.bell-labs.com
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id PAA23943; Mon, 17 Jul 2000 15:37:16 -0500
Message-ID: <39736E7E.A606ABCD@lucent.com>
Date: Mon, 17 Jul 2000 15:37:18 -0500
From: John Stanaway 
Reply-To: stanaway@lucent.com
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
Original-To: Henning Schulzrinne , SIP@lists.bell-labs.com
Subject: Re: [Fwd: [SIP] Early version of draft on SIP for 911 services]
References: <396F3D2D.5D719009@lucent.com> <39731E75.BE4257C1@lucent.com> <39734083.DE223411@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:
> 
> John Stanaway wrote:
> >
> > Henning,
> > I had the opportunity to read your paper on providing emergency call services.
> > This is a good start on this topic.  I have some comments and questions.
> >
> > In the introduction you might want to add another bullet describing how a PSAP
> > is determined in today's enhanced 911 systems.  In those systems, the calling
> > number is used to select the appropriate PSAP since this number is tied to a
> > physical location.  The PSAP queries the ALI for location information (address)
> > as well as a list (phone numbers) of the varoius emergency agencies that serve
> > that address.  The PSAP agent can transfer the call to the appropriate agency.
> > It should be noted that the PSAP agent stays on the call until the agency has
> > answered. (Maybe a more in depth description on the existing emergency service
> > (at least in the U.S.) would be useful.)
> 
> I've added some material to the -01 version, but clearly more detail is
> helpful. Since I'm not trying to provide a complete tutorial, just
> enough to understand the requirements for an Internet service, I want to
> avoid duplicating the 68-page NENA tutorial. I'd appreciate if you could
> point out any additional details that readers unfamiliar with 911
> operation should know.
> 
I believe you could describe e911 operation in 2-3 pages.  I'm not sure if it's
appropriate for an international audience but could serve as an example since
much of the document uses terms and concepts from e911.  Bellcore SR4163 has a
short call flow description.

> >
> > In your last bullet in the introduction, you seem to be mixing up what can be
> > provided by basic 911 and enhanced 911.  Basic 911 doesn't provide address
> > infomation via an ALI database. In basic 911, the service is usually provided by
> > the same switch the caller is connected to and thus the switch has more control
> > over what the caller can do. In enhanced 911, since multiple switches may be
> > involved, it is possible for the caller to hang up and make another call. It's
> > difficult to prevent this.  Since the PSAP has the address and phone number they
> > can still provide emergency services.
> 
> I thought even the first switch would recognize that this is a 911 call
> and thus could prevent this; I've heard all kinds of statements on what
> can and cannot be done during a 911 call. I don't really want to do an
> experiment, so if you have a reference to (say) a Bellcore or FCC spec
> or some other document, that would be most helpful.
>
The first switch (end-office) knows enough to route the call to an E911 tandem
switch.  The e911 tandem switch determines how to do selective routing to a
PSAP. 

The following is extracted from Bellcore document "E911 Service Description",
SR4163.

"If the PSAP attendant gets disconnected from the caller, the PSAP attendant may
make an outgoing call using the information provided to construct the 10-digit
ANI for dialing.

It should be noted that certain features traditionally provided with Basic 9-1-1
service are not provided with E9-1-1 service; these features are emergency
ringback, end-to-end called-party hold, and switch-hook status display. Other
E9-1-1 features replace the intent of these features and make them unnecessary."

> >
> > In section 2.2.4 on using LDAP.  Due to the nature of the information, you
> > probably want to restrict access to it and protect it from attacks.  You address
> > some of this in section 7.
> 
> Added; note, however, that this mapping from address to iPSAP is
> probably not very sensitive information. I can guess where my fire
> department is...
> 
By sensitive I meant critical.  You don't want this data compromised. 

> >
> > Maybe I missed it but how do you propose providing emergency services to
> > existing PSTN phones where the PSTN switches do not provide the service?  Would
> > a PSTN gateway or call agent (proxy) map the calling number to a physical
> > location?  This would require something like one of the solutions you described
> > in section 3.  Maybe you could explicitly discuss this?
> >
> 
> Given that a call to a PSTN-to-VoIP gateway can come from anywhere, it
> would seem that either the gateway has to access the standard ALI
> database to find the PSAP or just forward the call back into the PSTN,
> hopefully somehow "faking" the original calling number. (Not sure that
> is possible.)
> 
By ALI database I assume you mean Selective Routing data.  Selective Routing
database contains a mapping of calling number to PSAP and may be separate from
the ALI.  In this case (PSTN to IP) I was assuming that the IP network was
playing the role of an E911 tandem and would handle the 911 call.

> > I believe section 4 may be difficult to implement uniformly across multiple
> > domains.
> 
> I don't think this is a domain issue. As long as the end system
> recognizes that the call in progress is a 911 call, it can do whatever
> is appropriate. This is different than dumb end systems which don't have
> a clue that the string "9-1-1" just dialed has any special significance.
> 
In the case of e911, end offices don't have a clue except to route the call to a
dedicated trunk to an e911 tandem office.  In this case if the IP network is
providing the e911 tandem functionality, you don't (may not) want to provide
better grade of service to the IP endpoints than to the PSTN endpoints (all 911
calls are equal).  This is why, today, features of basic 911 (handled on a
single switch) don't have to work in e911 which may involve multiple switches
(see extracted text above).

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

-- 
John

John Stanaway
Lucent Technologies
263 Shuman Blvd.
Room 1A-437
Naperville, IL 60566
email: stanaway@lucent.com
phone: 630.713.4459
fax: 630.979.8998


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


From sip-admin@lists.bell-labs.com  Mon Jul 17 17:32:50 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21743
	for ; Mon, 17 Jul 2000 17:32:50 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 34D25443A3; Mon, 17 Jul 2000 17:32:30 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 869CC4434C
	for ; Mon, 17 Jul 2000 17:32:26 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA27447;
	Mon, 17 Jul 2000 17:32:26 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA04125;
	Mon, 17 Jul 2000 17:32:25 -0400 (EDT)
Message-ID: <39737B69.A78C3038@cs.columbia.edu>
Date: Mon, 17 Jul 2000 17:32:25 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: stanaway@lucent.com
Cc: SIP@lists.bell-labs.com
Subject: Re: [Fwd: [SIP] Early version of draft on SIP for 911 services]
References: <396F3D2D.5D719009@lucent.com> <39731E75.BE4257C1@lucent.com> <39734083.DE223411@cs.columbia.edu> <39736E7E.A606ABCD@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

John Stanaway wrote:
> 

> >
> I believe you could describe e911 operation in 2-3 pages.  I'm not sure if it's
> appropriate for an international audience but could serve as an example since
> much of the document uses terms and concepts from e911.  Bellcore SR4163 has a
> short call flow description.

I'm afraid I don't have access to Bellcore SRs (and can't afford the
typically $1k they seem to cost...).



> >
> By sensitive I meant critical.  You don't want this data compromised.

Agreed; the -01 wording alludes to this now.


> 
> > > I believe section 4 may be difficult to implement uniformly across multiple
> > > domains.
> >
> > I don't think this is a domain issue. As long as the end system
> > recognizes that the call in progress is a 911 call, it can do whatever
> > is appropriate. This is different than dumb end systems which don't have
> > a clue that the string "9-1-1" just dialed has any special significance.
> >
> In the case of e911, end offices don't have a clue except to route the call to a
> dedicated trunk to an e911 tandem office.  In this case if the IP network is
> providing the e911 tandem functionality, you don't (may not) want to provide
> better grade of service to the IP endpoints than to the PSTN endpoints (all 911
> calls are equal).  This is why, today, features of basic 911 (handled on a
> single switch) don't have to work in e911 which may involve multiple switches
> (see extracted text above).

I'm not talking about "switches" here at all - in an all-IP network, the
end system (as in, Internet telephone, PC, PDA, mobile IP device, etc.)
knows or can know that this call is special and needs special handling,
e.g., in disabling certain features. This is also necessary if end
systems are to provide sensitive information that should only be
included in 911 calls.


-- 
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 Jul 17 17:34:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22679
	for ; Mon, 17 Jul 2000 17:34:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BEE52443AC; Mon, 17 Jul 2000 17:33:53 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 4E363443AA
	for ; Mon, 17 Jul 2000 17:33:50 -0400 (EDT)
Received: from ss8networks.com (gw-ss8networks.storm.ca [209.87.234.122])
	by renown.cnchost.com
	id RAA07380; Mon, 17 Jul 2000 17:33:46 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <39737B4C.5EE6E0FE@ss8networks.com>
Date: Mon, 17 Jul 2000 17:31:56 -0400
From: Dave Walker 
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kurt Robohm 
Cc: sip-mib@egroups.com, SIP Mailing List ,
        wjl@mci.net
References: <4.3.2.7.2.20000717144438.00c98b70@shoe.reston.mci.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: [sip-mib] revised SIP MIB draft
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Kurt,

Thank-you for your comments.  My answers are in-line.

Kurt Robohm wrote:
> 
> All,
> I had reviewed a previous edition of the SIP MIB and logged a 
> number of inquiries as indicated below.  A good deal of the 
> objects I had questions or comments about now appear to not be 
> present in the latest edition.  I searched through the email 
> distro discussions and found no mention of having deleted these 
> objects, so I'm a bit confused.  Anyway, if anyone would like 
> to enlighten me a bit regarding my comments below, I'd appreciate 
> it.
> 
> Kurt Robohm
> Worldcom
> Ashburn Virginia
> 
> Object Name                     Inquiry
> 
> sipOrganization                 Where does the organization
>                                 information originate from?

It's a SIP header.  Value may typically be configured into the 
application by an enduser (UA) or via network management.

> 
> sipSummaryInRequests            How about similar object for
>                                 rejected request or responses?

Please take a look at the status code counters, particularly see 
sipStatusCodesTable and sipCommonStatusCodeTable.

> 
> sipStatsAckIns                  How about similar object for a
>                                 Nak?

There's no Nak method in RFC 2543.

>                                 Intent of object was to show
> sipStatsInfoTryingOuts          number of transactions
>                                 necessary to complete a call?
>                                 Intent of object was to show
> sipStatInfoRingingIns           number of devices involved in
>                                 the call route?
> 
> sipStatsClientBadRequestIns     Will objects be indexed for
>                                 every client?
> sipStatsClientBadRequestIns     Is there a client name object?
>                                 Will counter be incremented for
> sipStatsClientBadRequestIns     packets that are
>                                 bad/incomplete?
> 
> sipStatsClientBadRequestIns     Is there a client IP address
>                                 object?
>                                 Would lost packets be reason
> sipStatsClientReqTimeoutIns     for timeout- or is this counted
>                                 after a "trying" response is
>                                 rx?
>                                 Is this equivalent to an echo
> sipStatsClientLoopDetectedIns   on the line in older telephony
>                                 parlance?
> sipStatsServerGatewayTimeoutIns

As was pointed out at the IETF in Adelaide, there were far too
many counters in the MIB.  All of the counters above were replaced
by the class counters (in sipStatusCodesTable), and a generic 
mechanism was provided for counting specific status codes (in
sipCommonStatusCodeTable).

> 
> sipCurrentTransacations         Does this reflect number of
>                                 calls in progress?
>                                 Intent of objects in table to
> sipTransactionTable             provide real time info on
>                                 number of calls being handled
>                                 real time?

Transactions aren't calls.  The intent, as mentioned in Adelaide,
is to evolve the transaction table to a call leg table (probably 
for UAs only).  This hasn't been resolved yet, so no real changes 
were made.

> 
> sipTransCallingPartyContentType Intent of object was to provide
>                                 details on calls in progress?
> 
> SIP retry statistics            Do retries indicate any general
>                                 network problems?

That's one likely cause.  The interpretation of the data isn't a 
matter for the MIB.

> 
> sipRxProxyAuthPassword          Why is this object needed?
>                                 (seems like a security issue)

In Adelaide, it was also identified that support for SIP security 
mechanisms needs attention.  It still does.  The new draft was
primarily concerned with a base restructuring of the MIBs.


Best Regards,

Dave Walker
SS8 Networks
Ottawa, Canada


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


From sip-admin@lists.bell-labs.com  Mon Jul 17 17: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 ESMTP id RAA03992
	for ; Mon, 17 Jul 2000 17:54:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7611D443B0; Mon, 17 Jul 2000 17:53:29 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from nago.cs.colorado.edu (nago.cs.colorado.edu [128.138.202.19])
	by lists.bell-labs.com (Postfix) with ESMTP id B199544349
	for ; Mon, 17 Jul 2000 17:53:23 -0400 (EDT)
Received: from imix.cs.colorado.edu (imix.cs.colorado.edu [128.138.202.190])
	by nago.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6HLrMX00867
	for ; Mon, 17 Jul 2000 15:53:22 -0600 (MDT)
Received: from localhost (levis@localhost)
	by imix.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6HLrLu20565
	for ; Mon, 17 Jul 2000 15:53:21 -0600 (MDT)
X-Authentication-Warning: imix.cs.colorado.edu: levis owned process doing -bs
Date: Mon, 17 Jul 2000 15:53:21 -0600 (MDT)
From: Philip Levis 
To: sip@lists.bell-labs.com
In-Reply-To: <396CCDA5.34C9299D@fokus.gmd.de>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [SIP] Multiple sessions in SDP payload
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

I've looked over 2543 several times, and been unable to determine whether
an SDP payload can have multiple sessions specified within it. RFC 2327
(SDP) states that multiple sessions may be specified unless annnounced by
SAP.

I take this to mean that multiple SDP sessions may be specified. Is this
correct?

The next question is, what would multiple SDP sessions signify?

Phil




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


From sip-admin@lists.bell-labs.com  Mon Jul 17 19: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 ESMTP id TAA10427
	for ; Mon, 17 Jul 2000 19:11:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BB88B4436C; Mon, 17 Jul 2000 19:10:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from alpha.telecom-co.net (unknown [200.21.27.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 7922744349
	for ; Mon, 17 Jul 2000 19:10:37 -0400 (EDT)
Received: from MABOL ([200.21.27.154]) by alpha.telecom-co.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 38SAWL6Q; Mon, 17 Jul 2000 18:09:40 -0500
Message-ID: <004801bff044$33bfbf70$9a1b15c8@mabol.telefonia>
From: "=?koi8-r?Q?Mauricio_Bola=D3os_Arturo?=" 
To: 
Date: Mon, 17 Jul 2000 18:10:25 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Subject: [SIP] TCP Invite
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


Hi Everyone!

I have a SIP User Agent with TCP connection. The UAC send an INVITE request,
as it works over TCP, it doesn't need to retransmit requests and at this
moment it's waiting for a response. How much time should  be waiting for a
response?? What happen if this response never arrive to the UAC ?
I should use the INVITE expire header for this purpose ?

thanks a lot

Mauricio Bolanos Arturo
ITEC - TELECOM
Bogota Colombia




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


From sip-admin@lists.bell-labs.com  Mon Jul 17 19:37:22 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20392
	for ; Mon, 17 Jul 2000 19:37:22 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3398144398; Mon, 17 Jul 2000 19:36:58 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id BB0C54435D
	for ; Mon, 17 Jul 2000 19:36:54 -0400 (EDT)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA28197;
	Mon, 17 Jul 2000 16:37:09 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAA74032;
	Mon, 17 Jul 2000 16:36:52 -0700 (PDT)
Message-Id: <4.2.0.58.20000717131624.01b6e560@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 17 Jul 2000 16:30:41 -0700
To: Gonzalo Camarillo 
From: Rohan Mahy 
Subject: Re: [SIP] On Transcoding Device
Cc: rafi , sip@lists.bell-labs.com
In-Reply-To: <3972AC8A.46CDBB10@lmf.ericsson.se>
References: <006701bfefb2$e75e5740$8c40000a@sasi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,

This thread got me thinking about a related topic:  naming conventions for 
MCU conferences.  I think of transcoders as just simple (2-party) MCUs that 
supports multiple codecs.  Just like Gonzalo's transcoders, MCUs could also 
match on the user portion of Request-URI when forming an ad-hoc 
conference.  Let's call the parties using the same user portion as a "group".

One of the problems traditionally associated with MCU conferences when 
using a distributed signaling protocol, is how to decide when to free up 
resources.

Let's say you need a transcoder so that Alice can leave a voicemail message 
for Bob.  The voicemail system uses G.711 and G.729.  Alice is using a GSM 
mobile phone gateway (GSM codec).  If Alice sends a BYE, you want the 
transcoder to send a BYE to the voicemail system as well.  You could use 
session timer (and other mechnisms) to detect if Alice "went away" without 
sending a BYE.  In the two party case, if either party disappears, you can 
safely drop the call right?

Well, maybe not.  Say Alice gets an important call while leaving 
voicemail.  She  puts voicemail and hold.  She has music on hold, so her UA 
uses TRANSFER or Also to ask the transcoder/MCU to listen to musak. Before 
she can get back to voicemail, her UA crashes and forgets her call-ids and 
request URIs.  Now the MCU/transcoder has Musak streaming forever at Voicemail.

Basically, you have passive and active participants in a group. As long as 
there is at least one active participant, you should keep the group (and 
therefore all the passive participants) up.  This works well if you want 
some conferences to die after the initiator leaves (the initiator is the 
only active party), and for applications like call screening, call 
monitoring, call center coaching, etc.  For more advanced  mixing 
applications each party may be a member of more than one "group" of 
parties, and may send or receive media, or both.

I think a user-part naming convention for transcoders and MCUs would help 
here. I had in mind something along these lines:

   uri = scheme ":" [userpart "@" ] hostport *( ";" params )
   userpart = group  *( "+" group )
   group = group-id *( "," group-params )

So you can INVITE yourself to one or more groups, each group separated by a 
"+".  For each group, you could add optional parameters.

   group-params = participation | direction
   participation = "active" | "passive"
   direction = "send" | "recv" | "sendrecv"

The group ID selected for 3rd party call control is centralized so there 
are no conflicts on the MCU, but you could easily use a local call id and 
add you FQDN or IP address on the end separated by a "&".

   group-id = token | token "&" host

I believe that all these characters (+)  (,)  (&)  plus (=) are legal to 
use unescaped in the user part.

Behavior of the MCU is:  for each RTP sender, find out which groups they 
send on, and mix that media with all listeners of that set of groups which 
understand that media type.

Anyone have any comments on this?

thanks,
-rohan


At 11:49 PM 7/16/00 , Gonzalo Camarillo wrote:
>Hi,
>
>T receives two INVITEs, each one with an SDP. These two INVITEs can be
>matched betweeen them because they use the same URI in the Request-URI
>(in the example: session3371@transcoder.provider3.com).
>
>The trancoder has to bridge between the SDP of one INVITE and the SDP of
>the other one.
>That is, everything received on one side is sent to the other side and
>the other way around.
>
>Regards,
>
>Gonzalo
>
>
> > rafi wrote:
> >
> > Hi,
> >
> >
> >         In Draft  "draft-camarillo-3pcc-qos-00.txt"
> > in section 3, example is  given where
> > use of transcoding device is mentioned. This
> > device act as a "dial-up bridge" and  bridges two
> > audio stream from UAC - T and  T- UAS (where T
> > is transcoding service agent ) and vice versa. However
> > it is not clear how T comes  to know which of the  two
> > audio  stream it has to  bridge.
> >
> >
> > Thank You
> > Rafi Assadi H.M
> > Silicon Automation Systems
> > Bangalore
> >
> >
>
>--
>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
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/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 Jul 17 20:23:56 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08648
	for ; Mon, 17 Jul 2000 20:23:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2805344351; Mon, 17 Jul 2000 20:23:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by lists.bell-labs.com (Postfix) with ESMTP id 8858244349
	for ; Mon, 17 Jul 2000 20:23:44 -0400 (EDT)
Received: from esvir03nok.ntc.nokia.com (esvir03nok.ntc.nokia.com [131.228.10.152])
	by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6HCwHx29439
	for ; Mon, 17 Jul 2000 15:58:19 +0300 (EET DST)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir03nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.2) with ESMTP id ;
 Mon, 17 Jul 2000 15:57:47 +0300
Received: by esebh01nok with Internet Mail Service (5.5.2650.10)
	id <3053X6T9>; Mon, 17 Jul 2000 15:57:47 +0300
Message-ID: <11CD408013B6D2119BB50008C7EA510C03A8D0EE@eseis05nok>
From: Sapan.Bhatia@nokia.com
To: jdrosen@dynamicsoft.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Tunneling with SIP
Date: Mon, 17 Jul 2000 15:57:44 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

// "Fox, Mike" wrote:
// > 
// > Jonathan Rosenberg wrote:
// > > I would not advocate tunneling DHCP over SIP, HTTP over SIP,
// > > or SLP over
// > > SIP, since those protocols
// > > don't do the same thing SIP does. Same with megaco/mgcp.
// > > Tunneling them
// > > over SIP serves no purpose. SIP is not a good transfer
// > > protocol (see the
// > > Guidelines for Authors of SIP Extensions:
// > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-gui
// > >delines-00.txt).
// > >Just use the native transport define by the protocol.
// > 
// > Perhaps it would be too simple an extrapolation to 
// conclude that you are not
// > in favor of ...
// > http://www.ietf.org/internet-drafts/draft-deason-sip-soap-00.txt
// > 
// > Could you share your opinion? (I would mine, but few care 
// about it! ;-)
// 
// I do not believe that SIP is a useful RPC mechanism. None of its user
// discovery and registration capabilities are needed for RPC, neither
// are most of its proxy functions. As it is not an ideal transfer
// protocol, it is not good at carrying serialized objects of any large
// size.
// 
// -Jonathan R.
// 

Well, correct me if I'm wrong, but when you talk of ORPC over SIP, then the
ORPC mechanism would be handled by another protocol (like SOAP-XML) which
would encapsulate information such as Object ID's, Interface id's, context
information etc. So the user-discovery/registration capabilities of SIP
would not be required since object requests would not directly utilize the
capabilities of SIP, but of SOAP which is transferred as SIP payload (just
as it is in HTTP - <>). And also, the payload
would typically be used to relay ORPC request-responses and not large
serialized objects.


-Sapan Bhatia


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 01:00:20 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19378
	for ; Tue, 18 Jul 2000 01:00:20 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9CD9A4435D; Tue, 18 Jul 2000 00:59:53 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 157CF44336
	for ; Tue, 18 Jul 2000 00:59:50 -0400 (EDT)
Received: from dynamicsoft.com (1Cust114.tnt1.freehold.nj.da.uu.net [63.17.113.114])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA08106;
	Tue, 18 Jul 2000 01:01:13 -0400 (EDT)
Message-ID: <3973E512.501FEA68@dynamicsoft.com>
Date: Tue, 18 Jul 2000 01:03:14 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mauricio =?iso-8859-1?Q?Bola=D3os?= Arturo 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] TCP Invite
References: <004801bff044$33bfbf70$9a1b15c8@mabol.telefonia>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit



Mauricio BolaÓos Arturo wrote:
> 
> Hi Everyone!
> 
> I have a SIP User Agent with TCP connection. The UAC send an INVITE request,
> as it works over TCP, it doesn't need to retransmit requests and at this
> moment it's waiting for a response. How much time should  be waiting for a
> response?? 

Same as if it were UDP. If no 1xx is received, its 32s, I believe. If
you get a 1xx, its implementation dependent.

>What happen if this response never arrive to the UAC ?

What happens if you call someone on the phone and no one answers? At
some point you hang up. Same here.

> I should use the INVITE expire header for this purpose ?

You could; you can also CANCEL the request when you decide to give up.
Both will actually achieve the same result.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 01:01:51 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19946
	for ; Tue, 18 Jul 2000 01:01:51 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 970CF4439D; Tue, 18 Jul 2000 01:00:53 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5FB5444386
	for ; Tue, 18 Jul 2000 01:00:50 -0400 (EDT)
Received: from dynamicsoft.com (1Cust114.tnt1.freehold.nj.da.uu.net [63.17.113.114])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA08110;
	Tue, 18 Jul 2000 01:02:19 -0400 (EDT)
Message-ID: <3973E555.B963DED2@dynamicsoft.com>
Date: Tue, 18 Jul 2000 01:04:21 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Philip Levis 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Multiple sessions in SDP payload
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Philip Levis wrote:
> 
> I've looked over 2543 several times, and been unable to determine whether
> an SDP payload can have multiple sessions specified within it. RFC 2327
> (SDP) states that multiple sessions may be specified unless annnounced by
> SAP.

You can have multiple media streams (i.e., multiple m lines in the SDP).
For example, one audio and one video. 

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 01:16:37 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28616
	for ; Tue, 18 Jul 2000 01:16:37 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0B631443A3; Tue, 18 Jul 2000 01:15:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 737DC44369
	for ; Tue, 18 Jul 2000 01:15:40 -0400 (EDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Tue, 18 Jul 2000 00:12:07 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Tue, 18 Jul 2000 00:15:10 -0500
Message-ID: <2E532B03F035D3119AF40000F80932C32073F5@crchy28d.us.nortel.com>
From: "William Lee" 
To: "'Philip Levis'" 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Multiple sessions in SDP payload
Date: Tue, 18 Jul 2000 00:15:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF077.22B75D40"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF077.22B75D40
Content-Type: text/plain

Yes, according to the spec, multiple SDP sessions may be specified.  
At the 2nd SIP bake-off, we tested a trial implementation of our 
SDP parser/statemachine that sent and received multiple SDP sessions. 
No one supported this, and as far as I know no one else does today.

William Lee
williaml@nortelnetworks.com

> -----Original Message-----
> From:	Philip Levis [SMTP:levis@cs.colorado.edu]
> Sent:	Monday, July 17, 2000 4:53 PM
> To:	sip@lists.bell-labs.com
> Subject:	[SIP] Multiple sessions in SDP payload
> 
> I've looked over 2543 several times, and been unable to determine whether
> an SDP payload can have multiple sessions specified within it. RFC 2327
> (SDP) states that multiple sessions may be specified unless annnounced by
> SAP.
> 
> I take this to mean that multiple SDP sessions may be specified. Is this
> correct?
> 
> The next question is, what would multiple SDP sessions signify?
> 
> Phil
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01BFF077.22B75D40
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Multiple sessions in SDP payload




Yes, according to =
the spec, multiple SDP sessions may be specified.  

At the 2nd SIP =
bake-off, we tested a trial implementation of our 

SDP =
parser/statemachine that sent and received multiple SDP sessions. =


No one supported =
this, and as far as I know no one else does today.




William Lee

williaml@nortelnetworks.com



    

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

    From:   Philip Levis =
[SMTP:levis@cs.colorado.edu]

    Sent:   Monday, July 17, 2000 4:53 PM

    To:     sip@lists.bell-labs.com

    Subject:       =
 [SIP] Multiple sessions in SDP =
payload

    


    I've looked over 2543 several times, =
and been unable to determine whether

    an SDP payload can have multiple =
sessions specified within it. RFC 2327

    (SDP) states that multiple sessions =
may be specified unless annnounced by

    SAP.

    


    I take this to mean that multiple SDP =
sessions may be specified. Is this

    correct?

    


    The next question is, what would =
multiple SDP sessions signify?

    


    Phil

    

    

    

    


    _______________________________________________

    SIP mailing list

    SIP@lists.bell-labs.com

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

    




------_=_NextPart_001_01BFF077.22B75D40--


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 01:25:39 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04456
	for ; Tue, 18 Jul 2000 01:25:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0747044369; Tue, 18 Jul 2000 01:25:21 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from nago.cs.colorado.edu (nago.cs.colorado.edu [128.138.202.19])
	by lists.bell-labs.com (Postfix) with ESMTP id 99E9E44336
	for ; Tue, 18 Jul 2000 01:25:18 -0400 (EDT)
Received: from imix.cs.colorado.edu (imix.cs.colorado.edu [128.138.202.190])
	by nago.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6I5PEX04464;
	Mon, 17 Jul 2000 23:25:14 -0600 (MDT)
Received: from localhost (levis@localhost)
	by imix.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6I5PE221619;
	Mon, 17 Jul 2000 23:25:14 -0600 (MDT)
X-Authentication-Warning: imix.cs.colorado.edu: levis owned process doing -bs
Date: Mon, 17 Jul 2000 23:25:13 -0600 (MDT)
From: Philip Levis 
To: Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Multiple sessions in SDP payload
In-Reply-To: <3973E555.B963DED2@dynamicsoft.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

On Tue, 18 Jul 2000, Jonathan Rosenberg wrote:

> You can have multiple media streams (i.e., multiple m lines in the SDP).
> For example, one audio and one video. 

I'm concerned with sessions, not streams. Not having multiple streams in a
given SDP session description would be problematic for the media
negotation that goes on between parties.

2327:

When SDP is conveyed by SAP, only one session description is allowed per
packet.  When SDP is conveyed by other means, many SDP session
descriptions may be concatenated together (the `v=' line indicating the
start of a session description terminates the previous description).

PINT does so with a defined semantic meaning; I'm wondering what it
corresponds to in standard SIP. It seems to me to be a useful mechanism
for 3pcc.

Phil




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


From sip-admin@lists.bell-labs.com  Tue Jul 18 01:43:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15383
	for ; Tue, 18 Jul 2000 01:43:48 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 43489443AA; Tue, 18 Jul 2000 01:43:40 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by lists.bell-labs.com (Postfix) with SMTP id E6DFF4436C
	for ; Tue, 18 Jul 2000 01:43:34 -0400 (EDT)
Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jul 2000 22:43:14 -0700 (Pacific Daylight Time)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58)
	id <39147785>; Mon, 17 Jul 2000 22:43:13 -0700
Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C31AF@red-msg-24.redmond.corp.microsoft.com>
From: Christian Huitema 
To: "'William Lee'" ,
        "'Philip Levis'" 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Multiple sessions in SDP payload
Date: Mon, 17 Jul 2000 22:43:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFF07B.0E515C80"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF07B.0E515C80
Content-Type: text/plain;
	charset="ISO-8859-1"

The problem is, there is a fundamental contradiction between two
requirements. If I include 3 "m=audio" lines, do they describe 3 ways to
pass audio, such as IPv4, IPv6 and POTS, or do I describe 3 audio channels
that should be deployed in parallel? My take so far would be to use multiple
instance of the same media within a single SDP payload to describe
alternative encodings, and to use multiple SDP payloads, using MIME
multipart, to encode several parallel sessions.
 
Christian Huitema

-----Original Message-----
From: William Lee [mailto:williaml@nortelnetworks.com]
Sent: Monday, July 17, 2000 10:15 PM
To: 'Philip Levis'
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Multiple sessions in SDP payload



Yes, according to the spec, multiple SDP sessions may be specified.  
At the 2nd SIP bake-off, we tested a trial implementation of our 
SDP parser/statemachine that sent and received multiple SDP sessions. 
No one supported this, and as far as I know no one else does today. 

William Lee 
williaml@nortelnetworks.com 

	-----Original Message----- 
From:   Philip Levis [SMTP:levis@cs.colorado.edu] 
Sent:   Monday, July 17, 2000 4:53 PM 
To:     sip@lists.bell-labs.com 
Subject:        [SIP] Multiple sessions in SDP payload 

	I've looked over 2543 several times, and been unable to determine
whether 
an SDP payload can have multiple sessions specified within it. RFC 2327 
(SDP) states that multiple sessions may be specified unless annnounced by 
SAP. 

	I take this to mean that multiple SDP sessions may be specified. Is
this 
correct? 

	The next question is, what would multiple SDP sessions signify? 

	Phil 




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


------_=_NextPart_001_01BFF07B.0E515C80
Content-Type: text/html;
	charset="ISO-8859-1"




RE: [SIP] Multiple sessions in SDP payload




The 
problem is, there is a fundamental contradiction between two requirements. If I 
include 3 "m=audio" lines, do they describe 3 ways to pass audio, such as IPv4, 
IPv6 and POTS, or do I describe 3 audio channels that should be deployed in 
parallel? My take so far would be to use multiple instance of the same media 
within a single SDP payload to describe alternative encodings, and to use 
multiple SDP payloads, using MIME multipart, to encode several parallel 
sessions.


 


Christian Huitema



  
-----Original Message-----
From: William Lee 
  [mailto:williaml@nortelnetworks.com]
Sent: Monday, July 17, 2000 
  10:15 PM
To: 'Philip Levis'
Cc: 
  sip@lists.bell-labs.com
Subject: RE: [SIP] Multiple sessions in SDP 
  payload


  
Yes, according to the spec, multiple 
  SDP sessions may be specified.  
At the 2nd SIP bake-off, we tested a trial implementation of our 
  
SDP parser/statemachine that 
  sent and received multiple SDP sessions. 
No one supported this, and as far as I know no one else does 
  today. 

  
William Lee 
williaml@nortelnetworks.com 

  
    
    
    -----Original Message----- 
    From:   Philip Levis [SMTP:levis@cs.colorado.edu] 
    Sent:   Monday, July 17, 2000 4:53 PM 
    To:     sip@lists.bell-labs.com 
    Subject:        [SIP] Multiple sessions in SDP payload 
    
    
    I've looked over 2543 several times, and been 
    unable to determine whether 
    an SDP 
    payload can have multiple sessions specified within it. RFC 2327 
    
    (SDP) states that multiple sessions may be 
    specified unless annnounced by 
    SAP. 
    
    
    I take this to mean that multiple SDP sessions 
    may be specified. Is this 
    correct? 
    
    
    
    The next question is, what would multiple SDP 
    sessions signify? 
    
    
    Phil 



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


------_=_NextPart_001_01BFF07B.0E515C80--


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 01:46:42 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16952
	for ; Tue, 18 Jul 2000 01:46:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C3177443B1; Tue, 18 Jul 2000 01:46:37 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D94ED443A3
	for ; Tue, 18 Jul 2000 01:46:34 -0400 (EDT)
Received: from dynamicsoft.com (1Cust114.tnt1.freehold.nj.da.uu.net [63.17.113.114])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA08205;
	Tue, 18 Jul 2000 01:48:04 -0400 (EDT)
Message-ID: <3973F00D.3F6A4DBB@dynamicsoft.com>
Date: Tue, 18 Jul 2000 01:50:05 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fox, Mike" 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] How to stop a Lawnmower Man attack?
References: <613A6A6A3F09D3118F5C00508B2C24FEAD8B44@sd_exchange.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Fox, Mike" wrote:
> 
> The zombie never belongs to the attacker it belongs to some other
> unsuspecting dupe so is can be very hard (impossible?) to find who to
> prosecute later.

In this case, how are you controlling it to make it make all those
random phone calls?

> 
> Not that it has been widely implemented, a GK can be used in conjunction
> with a firewall so that only GK routed calls can be originated or accepted
> by a Zone. The administrative problem of protecting a few GKs and a Firewall
> seems more tractable than protecting all possible terminals.

You can certainly do this for SIP also; see:
http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-firewalls-00.txt

Using firewalls though to prevent people from getting out is ultimateily
futile.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 01: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 ESMTP id BAA18858
	for ; Tue, 18 Jul 2000 01:50:20 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CD60D443BE; Tue, 18 Jul 2000 01:50:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 43007443B4
	for ; Tue, 18 Jul 2000 01:50:14 -0400 (EDT)
Received: from dynamicsoft.com (1Cust114.tnt1.freehold.nj.da.uu.net [63.17.113.114])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA08218;
	Tue, 18 Jul 2000 01:51:43 -0400 (EDT)
Message-ID: <3973F0E8.5FC4318A@dynamicsoft.com>
Date: Tue, 18 Jul 2000 01:53:44 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shail Bhatnagar 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Usage of DNS SRV query
References: <39733BC3.FBC53234@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Shail Bhatnagar wrote:
> 
> A proxy can route a request using different mechanisms like :
> 
> (a) Route header in incoming request
> 
> (b) Contact headers obtained from REGISTER messages
> 
> (c) Contact headers obtained from 3xx response
> 
> (d) Outgoing Request-URI is same as incoming Request-URI ( it got a
> call for a foreign domain or host portion of incoming Request-URI
> is not the proxy)

Any location other location service can be used as well - LDAP database,
for example.

> 
> and there may be/are others. Should a proxy use the DNS SRV query
> for all the above cases.

Yes.

> I guess, SRV query should not be used if proxy has some static
> routes or information that it uses for call routing.

Not neccesarily. I might have a static route that maps calls to +1 973
to gateways.com:

INVITE tel:19735551212 SIP/2.0 ---> INVITE sip:19735551212@gateways.com

where the actual ip address of gateways.com is obatined from DNS.

-Jonathan R.



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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 02: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 ESMTP id CAA14895
	for ; Tue, 18 Jul 2000 02:34:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A8E5644354; Tue, 18 Jul 2000 02:34:20 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id 8E3F94433A
	for ; Tue, 18 Jul 2000 02:34:17 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7J1WH1>; Mon, 17 Jul 2000 23:34:39 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Dvir Oren'" , SIP 
Subject: RE: [SIP] Local Calling
Date: Mon, 17 Jul 2000 23:34:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

HI Dvir,

You don't need any tricks - its all handled in the way the protocol works.

Firstsly, let me clarify my definition of a User-Agent instance. In my mind
I take the term User-Agent as the call state associated with _one-half_ of a
call (amongst other things - I'm not trying to come up with a formal
definition here guys). So IMO if you are proposing local calling within
_one_ instance of User-Agent then this doesn't make sense in a SIP sense and
so you are on you own. 

If however you are simply trying to local call within the same SIP
User-Agent Application (where the Application is attached to a port (eg
5060) and creates User-Agent instances whenever it receives a new inbound &
outbound call attempt), then the solution is trivial.

Your "local calling" uses the machine's IP loopback driver so an INVITE
sent to a Request-URI with different username at the same machine will
simply appear at the packet queue of the Application. 

This causes a new User-Agent instance to be created, in particular a
"terminating" User-Agent instance. The other User-Agent instance is
obviously an "originating" User-Agent instance. [Once again this also
depends on your implementation approach.]

So now determining which User-Agent instance a Request or Response is
destined for becomes a trivial of comparing the To & From fields. 

BYE xxxxxxx
Via: SIP/2.0/UDP myserver.com
To: b@myserver.com
From: a@myserver 
Call-ID: qwerty

is destined for the terminating User-Agent. 

BYE xxxxxxx
Via: SIP/2.0/UDP myserver.com
From: b@myserver.com
To: a@myserver 
Call-ID: qwerty

is destined for the originating User-Agent. 

SIP/2.0 200 Ok
Via: SIP/2.0/UDP myserver.com
To: b@myserver.com
From: a@myserver 
Call-ID: qwerty

is destined for the originating User-Agent. 

SIP/2.0 200 Ok
Via: SIP/2.0/UDP myserver.com
From: b@myserver.com
To: a@myserver 
Call-ID: qwerty

is destined for the terminating User-Agent. 

Note: the terminating User-Agent MUST add a tag to the To of the final
INVITE response but this doesn't affect how the above logic works.

You could use different ports for each user-agent instance as well.

Hope that doesn't confuse you more. :)

Cheers,

Robert.

-- My opinions are my own. Nobody else listens to them anyway. --

> -----Original Message-----
> From: Dvir Oren [mailto:dvir@lucidvon.com]
> Sent: Monday, July 17, 2000 5:01 PM
> To: SIP
> Subject: [SIP] Local Calling
> 
> 
> I've been trying to allow 'local calling' within my user agent, and
> ran into some difficulties.  I was wondering if there is any internet
> draft or some kind of protcol to do this.
> 
> By 'local calls' I mean a call in which the caller and callee 
> share the 
> same user agent client/server.  This causes some difficulties, since
> the UAC and UAS share the same pool of call states.  When the callee
> receives an INVITE, there would already be a call with those
> parameters since it was initiated from from the same place.
> 
> At this point I see two scenarios:
> 1.  The UAS added a tag to the 'to' field, however the UAC has sent
> another INVITE.  When compared, the INVITEs will not match, and now
> the UAS will try to initiate a new call.
> 
> 2.  The UAS did not add a tag to the 'to' field, but when 
> compared, it 
> will already find the call that the caller initiated.
> 
> Any ideas?
> 
> -- 
> Dvir Oren               
> Lucid VON Ltd.     
> 9 Saloniki St.,        Tel-Aviv       Israel
> Tel:  +972 3 644 3038  Fax:  +972 3 644 3039
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 03:15:31 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02497
	for ; Tue, 18 Jul 2000 03:15:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BFF824439D; Tue, 18 Jul 2000 03:14:51 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from giasmd01.vsnl.net.in (giasmd01.vsnl.net.in [202.54.6.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 2A73A44336
	for ; Tue, 18 Jul 2000 03:14:45 -0400 (EDT)
Received: from josetel (m30.pppmad.vsnl.net.in [202.54.35.135])
	by giasmd01.vsnl.net.in (8.9.3/8.9.3) with SMTP id MAA14249
	for ; Tue, 18 Jul 2000 12:51:31 +0530 (IST)
Message-ID: <004401bff062$bdff4e30$a164a8c0@josetel>
From: "Jose Cherian. P." 
To: 
Date: Tue, 18 Jul 2000 12:49:05 +1000
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] vovida stack
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Dear All,
I am fresh to SIP
I am trying to evaluate the vovida stack for SIP
The stack compiled easily on RedHat6.2
However, when I tried to run the sip user agent (sua), 
it is giving the error "cannot open /dev/ixj0"

Now, is it possible to run this with the help of a sound card?
is the phone jack card mandatory?

thanks in advance
Jose Cherian P.






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


From sip-admin@lists.bell-labs.com  Tue Jul 18 03:35:32 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11081
	for ; Tue, 18 Jul 2000 03:35:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 00D68443A2; Tue, 18 Jul 2000 03:35:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id 71EEA44369
	for ; Tue, 18 Jul 2000 03:35:14 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7J1WJ5>; Tue, 18 Jul 2000 00:35:37 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Jonathan Rosenberg'" 
Cc: sip@lists.bell-labs.com
Date: Tue, 18 Jul 2000 00:35:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Contact in final INVITE response.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi Jonathan,

At the SuperOp interop testing I found that some implementations were
sending SIP messages from source ports that they did not expect responses
on. This is fine in itself but causes problems when you receive final INVITE
responses that 
a) you do not have call state for (early teardown or crash perhaps?).
b) and do not contain a Contact.

Now for 2xx responses the RFC2543bis already says the a Contact MUST be
included so this is not an issue.
For 3xx responses the Contact has a different purpose.

But for error responses, there is no way to return the ACK to stop the final
response retransmission. You can simply "guess" a return address/port by
simply sending it back to the where it can from but that doesn't work in the
situation above.

So, do we need to change this section to say that a Contact MUST be included
in all 4xx,5xx,6xx responses as well? [It isn't possible to say that a
Contact is only a MUST if the source port cannot be used for a return
address.]

Regards,

Robert.

-- My opinions are my own. Nobody else listens to them anyway. --


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 05:05:54 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14162
	for ; Tue, 18 Jul 2000 05:05:54 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C7E11443AC; Tue, 18 Jul 2000 05:03:32 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 851D044336; Tue, 18 Jul 2000 05:03:25 -0400 (EDT)
Received: from oleane  (dyn-1-1-161.Vin.dialup.oleane.fr [195.25.4.161])  by smtp1.cluster.oleane.net  with SMTP id LAA02776; Tue, 18 Jul 2000 11:02:23 +0200 (CEST)
Message-ID: <013401bff097$20cd0be0$0401a8c0@oleane.com>
From: "mg263-8" 
To: 
Date: Tue, 18 Jul 2000 11:04:02 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0131_01BFF0A7.E194E720"
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] Implementing H.323
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_0131_01BFF0A7.E194E720
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

"Implementing H.323": the VoIP deployment scenario
International conference, Paris, 10-13 October
http://www.upperside.fr/bah323.htm

=20

------=_NextPart_000_0131_01BFF0A7.E194E720
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable









"Implementing H.323": the VoIP =
deployment scenario

International conference, Paris, 10-13 =
October


http://www.upperside.fr/bah32=
3.htm


 


 


------=_NextPart_000_0131_01BFF0A7.E194E720--



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


From sip-admin@lists.bell-labs.com  Tue Jul 18 05:24:58 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20312
	for ; Tue, 18 Jul 2000 05:24:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 25839443A1; Tue, 18 Jul 2000 05:24:47 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 3B05B44336
	for ; Tue, 18 Jul 2000 05:24:43 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA11581; Tue, 18 Jul 2000 10:22:40 +0100 (BST)
From: "Jo Hornsby" 
To: "Fairlie-Cuninghame, Robert" ,
        "'Jonathan Rosenberg'" 
Cc: 
Subject: RE: [SIP] Contact in final INVITE response.
Date: Tue, 18 Jul 2000 10:22:38 +0100
Message-ID: <003001bff099$b7136f70$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: 
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> At the SuperOp interop testing I found that some implementations
> were sending SIP messages from source ports that they did not
> expect responses on.

I suspect this is not atypical, which is why the use of
a received-port parameter in Vias is of dubious merit (there was
some discussion about this a while back, as I remember).

> This is fine in itself but causes problems when
> you receive final INVITE
> responses that 
> a) you do not have call state for (early teardown or crash perhaps?).
> b) and do not contain a Contact.

Interesting.

> Now for 2xx responses the RFC2543bis already says the a Contact
> MUST be included so this is not an issue.
> For 3xx responses the Contact has a different purpose.
> 
> But for error responses, there is no way to return the ACK to 
> stop the final response retransmission. You can simply "guess" a
> return address/port by simply sending it back to the where it can
> from but that doesn't work in the situation above.

You are right in that it won't typically work for UDP, but you
might get away with it over TCP.

> So, do we need to change this section to say that a Contact MUST 
> be included in all 4xx,5xx,6xx responses as well? [It isn't possible
> to say that a Contact is only a MUST if the source port cannot be
> used for a return address.]

I recall some discussion a while back about using Contact to give
some sort of "error information" in the case of 4xx, 5xx, 6xx; if
you look in the most recent bis (July), there is also some wording
to that affect.

Note that this aside, making Contact mandatory for 4xx, 5xx, 6xx
doesn't solve all problems, since it is defined to have different
semantics for a 485 (Ambiguous), and, indeed, 3xx.

If we don't get a solution for this, in the worse case scenario,
it's only going to result in 7 pointless transmissions...is this
so much of a problem (whatever it was failed anyhoo)?

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 Jul 18 06:36:56 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14367
	for ; Tue, 18 Jul 2000 06:36:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D812443A5; Tue, 18 Jul 2000 06:36:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id CDAE544336
	for ; Tue, 18 Jul 2000 06:36:11 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14057;
	Tue, 18 Jul 2000 06:36:11 -0400 (EDT)
Message-Id: <200007181036.GAA14057@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Date: Tue, 18 Jul 2000 06:36:10 -0400
Subject: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-00.txt,.ps
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: SIP: Session Initiation Protocol
	Author(s)	: M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg
	Filename	: draft-ietf-sip-rfc2543bis-00.txt,.ps
	Pages		: 179
	Date		: 17-Jul-00
	
The Session Initiation Protocol (SIP) is an application-layer control
(signaling) protocol for creating, modifying and terminating sessions
with one or more participants. These sessions include Internet
multimedia conferences, Internet telephone calls and multimedia
distribution. Members in a session can communicate via multicast or
via a mesh of unicast relations, or a combination of these.
SIP invitations used to create sessions carry session descriptions
which allow participants to agree on a set of compatible media types.
SIP supports user mobility by proxying and redirecting requests to
the user's current location. Users can register their current
location.  SIP is not tied to any particular conference control
protocol. SIP is designed to be independent of the lower-layer
transport protocol and can be extended with additional capabilities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-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-rfc2543bis-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-rfc2543bis-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:	<20000717150104.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-rfc2543bis-00.txt

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

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

--OtherAccess--

--NextPart--




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


From sip-admin@lists.bell-labs.com  Tue Jul 18 06:55:18 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20911
	for ; Tue, 18 Jul 2000 06:55:17 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9E16F44370; Tue, 18 Jul 2000 06:55:12 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id 4038644336
	for ; Tue, 18 Jul 2000 06:55:09 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7J1WR8>; Tue, 18 Jul 2000 03:55:32 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Jo Hornsby'" ,
        "'Jonathan Rosenberg'" 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Contact in final INVITE response.
Date: Tue, 18 Jul 2000 03:55:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Jo,

Forgive me, I wrote the statement backwards, I meant to say a number of
people were sending INVITE error responses from ports they were not
expecting the ACK to be sent to. [The ACK is sort of a response to the
response.] This is perfectly legal.

The received response will have a Via field that only has your own IP
address/hostname in it (which is of not use in routing the ACK). 

You seem to have worked out what I meant anyway. [Thank-you]

Yes the bis says something about error-information in 4xx,5xx,6xx but I
don't think this is necessarily mutually exclusive with putting a sip: URL
in there for ACK routing (as for 2xx). I don't think that a SIP URL
providing error-information for a SIP error is a good thing (although I'm
sure we can find some people to disagree).

Yes there is still a problem for 3xx & 485 Ambiguous but its better to fix
what can be fixed, right. Interestingly, if a redirect server is idempotent
in its routing then it can be stateless (ie, it wouldn't retransmit the
final response).

No, I'm sure 7 retransmissions wouldn't kill the network but it makes it
more difficult to diagnose real problems if you don't fix the "not-really"
real protocol problems, right?

Robert.

> -----Original Message-----
> From: Jo Hornsby [mailto:jhornsby@ubiquity.net]
> Sent: Tuesday, July 18, 2000 5:23 PM
> To: Fairlie-Cuninghame, Robert; 'Jonathan Rosenberg'
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] Contact in final INVITE response.
> 
> 
> > At the SuperOp interop testing I found that some implementations
> > were sending SIP messages from source ports that they did not
> > expect responses on.
> 
> I suspect this is not atypical, which is why the use of
> a received-port parameter in Vias is of dubious merit (there was
> some discussion about this a while back, as I remember).
> 
> > This is fine in itself but causes problems when
> > you receive final INVITE
> > responses that 
> > a) you do not have call state for (early teardown or crash 
> perhaps?).
> > b) and do not contain a Contact.
> 
> Interesting.
> 
> > Now for 2xx responses the RFC2543bis already says the a Contact
> > MUST be included so this is not an issue.
> > For 3xx responses the Contact has a different purpose.
> > 
> > But for error responses, there is no way to return the ACK to 
> > stop the final response retransmission. You can simply "guess" a
> > return address/port by simply sending it back to the where it can
> > from but that doesn't work in the situation above.
> 
> You are right in that it won't typically work for UDP, but you
> might get away with it over TCP.
> 
> > So, do we need to change this section to say that a Contact MUST 
> > be included in all 4xx,5xx,6xx responses as well? [It isn't possible
> > to say that a Contact is only a MUST if the source port cannot be
> > used for a return address.]
> 
> I recall some discussion a while back about using Contact to give
> some sort of "error information" in the case of 4xx, 5xx, 6xx; if
> you look in the most recent bis (July), there is also some wording
> to that affect.
> 
> Note that this aside, making Contact mandatory for 4xx, 5xx, 6xx
> doesn't solve all problems, since it is defined to have different
> semantics for a 485 (Ambiguous), and, indeed, 3xx.
> 
> If we don't get a solution for this, in the worse case scenario,
> it's only going to result in 7 pointless transmissions...is this
> so much of a problem (whatever it was failed anyhoo)?
> 
> Cheers,
> 
> 
>  - Jo.
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 07:22:45 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01610
	for ; Tue, 18 Jul 2000 07:22:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7A6A1443AE; Tue, 18 Jul 2000 07:22:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id 86EF444336
	for ; Tue, 18 Jul 2000 07:22:03 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7J1WSZ>; Tue, 18 Jul 2000 04:22:26 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Henning Schulzrinne'" 
Cc: "'Gethin Liddell'" , sip@lists.bell-labs.com
Subject: RE: [SIP] SIP URL telephone-subscriber syntax.
Date: Tue, 18 Jul 2000 04:22:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Ok, let's restart this whole decussion again now that we have something to
work from.

Please explain why

sip:ABCD;telparam=telvalue@gateway;user=phone

shouldn't be parsed as host ABCD with a SIP parameter "telparam" which has a
value of "telvalue@gateway". [Assuming that the parser _is_ normally capable
of parsing semicolons in the user part.]

Looking at the latest RFC2543bis draft (just posted) the '@ is a legal
parameter character:

  paramchar       = param-reserved | unreserved | escaped
  param-reserved  = "[" | "]" | "/" | "?" | ":" | "@" | "&" | "+" | "$"

If the parser doesn't understand that user=phone parameter then is should
look like user@host, right ? (Where the user part may contain semicolons).

So how do you parse something like this ?

Robert 

-- My opinions are my own. Nobody else listens to them anyway. -- 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: Friday, July 07, 2000 10:44 PM
> To: Fairlie-Cuninghame, Robert
> Cc: 'Gethin Liddell'; sip@lists.bell-labs.com; 'Jonathan Rosenberg'
> Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
> 
> 
> Frankly, I thought we solved this problem already several 
> days ago? Why
> invent a kludge that no other URL scheme is using to solve a 
> non-issue?
> -- 
> 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 Jul 18 07:41:42 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08247
	for ; Tue, 18 Jul 2000 07:41:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 050BB443A5; Tue, 18 Jul 2000 07:41:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.pulver.com (unknown [192.246.69.133])
	by lists.bell-labs.com (Postfix) with ESMTP id BCC0744370
	for ; Tue, 18 Jul 2000 07:41:33 -0400 (EDT)
Received: from cs.columbia.edu ([63.89.18.25])
	by mail.pulver.com (8.9.2/8.9.2) with ESMTP id HAA05998;
	Tue, 18 Jul 2000 07:40:54 -0400 (EDT)
Message-ID: <39744459.E3448427@cs.columbia.edu>
Date: Tue, 18 Jul 2000 07:49:45 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: William Lee 
Cc: "'Philip Levis'" , sip@lists.bell-labs.com
Subject: Re: [SIP] Multiple sessions in SDP payload
References: <2E532B03F035D3119AF40000F80932C32073F5@crchy28d.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



> William Lee wrote:
> 
> Yes, according to the spec, multiple SDP sessions may be specified.
> At the 2nd SIP bake-off, we tested a trial implementation of our
> SDP parser/statemachine that sent and received multiple SDP sessions.
> No one supported this, and as far as I know no one else does today.

sipc has supported multiple media (audio, video, whiteboard) for more
than a year, including multiple instances of the same media type.
However, I would encourage people coming to the bake-off with PC-based
UAs to implement multiple media, including adding and deleting streams
in mid-call. This will be one of the multi-party test scenarios.


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 08:16:17 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21304
	for ; Tue, 18 Jul 2000 08:16:16 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 34C6A44370; Tue, 18 Jul 2000 08:15:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.pulver.com (unknown [192.246.69.133])
	by lists.bell-labs.com (Postfix) with ESMTP id 2185144336
	for ; Tue, 18 Jul 2000 08:15:42 -0400 (EDT)
Received: from cs.columbia.edu ([63.89.18.25])
	by mail.pulver.com (8.9.2/8.9.2) with ESMTP id IAA06122;
	Tue, 18 Jul 2000 08:14:33 -0400 (EDT)
Message-ID: <39744C3C.A2A6808F@cs.columbia.edu>
Date: Tue, 18 Jul 2000 08:23:24 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
Cc: "'Gethin Liddell'" , sip@lists.bell-labs.com
Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Since the top-level structure is "sip: userinfo @ hostport". Thus, split
the URL into the "pre-@" and "post-@" parts. Parse each independently.

However, I agree that given that the 'userinfo @' is optional,
suggesting escaping of @ is probably wise. In general, escaping is only
needed if there's an ambiguity, so that in practice, something like 

user@host?Contact=sip:foo@bar 

will/should work, even though the escaped version

user@host?Contact=sip%3afoo%40bar

is safer. I'll be adding this to the torture test set.

"Fairlie-Cuninghame, Robert" wrote
> 
> Ok, let's restart this whole decussion again now that we have something to
> work from.
> 
> Please explain why
> 
> sip:ABCD;telparam=telvalue@gateway;user=phone
> 
> shouldn't be parsed as host ABCD with a SIP parameter "telparam" which has a
> value of "telvalue@gateway". [Assuming that the parser _is_ normally capable
> of parsing semicolons in the user part.]
> 
> Looking at the latest RFC2543bis draft (just posted) the '@ is a legal
> parameter character:
> 
>   paramchar       = param-reserved | unreserved | escaped
>   param-reserved  = "[" | "]" | "/" | "?" | ":" | "@" | "&" | "+" | "$"
> 
> If the parser doesn't understand that user=phone parameter then is should
> look like user@host, right ? (Where the user part may contain semicolons).
> 
> So how do you parse something like this ?
> 
> Robert
> 
> -- My opinions are my own. Nobody else listens to them anyway. --
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> > Sent: Friday, July 07, 2000 10:44 PM
> > To: Fairlie-Cuninghame, Robert
> > Cc: 'Gethin Liddell'; sip@lists.bell-labs.com; 'Jonathan Rosenberg'
> > Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
> >
> >
> > Frankly, I thought we solved this problem already several
> > days ago? Why
> > invent a kludge that no other URL scheme is using to solve a
> > non-issue?
> > --
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> >
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 10:14:17 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13459
	for ; Tue, 18 Jul 2000 10:14:17 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4F04F4435F; Tue, 18 Jul 2000 10:13:21 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CEB2A44336
	for ; Tue, 18 Jul 2000 10:13:17 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA09386;
	Tue, 18 Jul 2000 10:14:29 -0400 (EDT)
Message-ID: <397466C2.42AFFAC@dynamicsoft.com>
Date: Tue, 18 Jul 2000 10:16:34 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema 
Cc: "'William Lee'" ,
        "'Philip Levis'" , sip@lists.bell-labs.com
Subject: Re: [SIP] Multiple sessions in SDP payload
References: <2E3FA0558747934A8F753CC533A3F6DF043C31AF@red-msg-24.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


Christian Huitema wrote:
> The problem is, there is a fundamental contradiction between two requirements. If I include 3 "m=audio" lines, do they describe
> 3 ways to pass audio, such as IPv4, IPv6 and POTS, or do I describe 3 audio channels that should be deployed in parallel? My
> take so far would be to use multiple instance of the same media within a single SDP payload to describe alternative encodings,
> and to use multiple SDP payloads, using MIME multipart, to encode several parallel sessions.

I think three lines of the same type means the same thing it does in
SAPs usage - parallel media streams, not alternatives. This, in fact, is
necessary as per the other thread on sending DTMF using rfc2833 to third
party application servers.


As for multiple sessions per SDP, I don't know what the value of this
would be. rfc2543 is silent on this, and I would suggest it be
disallowed within SIP.

-Jonathan R.

>        -----Original Message-----
>        From: William Lee [mailto:williaml@nortelnetworks.com]
>        Sent: Monday, July 17, 2000 10:15 PM
>        To: 'Philip Levis'
>        Cc: sip@lists.bell-labs.com
>        Subject: RE: [SIP] Multiple sessions in SDP payload
> 
>        Yes, according to the spec, multiple SDP sessions may be specified.  
>        At the 2nd SIP bake-off, we tested a trial implementation of our 
>        SDP parser/statemachine that sent and received multiple SDP sessions. 
>        No one supported this, and as far as I know no one else does today. 



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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 10: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 ESMTP id KAA17867
	for ; Tue, 18 Jul 2000 10:23:00 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2CFAE443C1; Tue, 18 Jul 2000 10:22:13 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hotmail.com (f247.law7.hotmail.com [216.33.237.247])
	by lists.bell-labs.com (Postfix) with SMTP id A4FE144336
	for ; Tue, 18 Jul 2000 10:22:07 -0400 (EDT)
Received: (qmail 99424 invoked by uid 0); 18 Jul 2000 14:21:53 -0000
Message-ID: <20000718142153.99423.qmail@hotmail.com>
Received: from 164.164.6.34 by www.hotmail.com with HTTP;
	Tue, 18 Jul 2000 07:21:53 PDT
X-Originating-IP: [164.164.6.34]
From: "rahul pande" 
To: sip@lists.bell-labs.com
Date: Tue, 18 Jul 2000 14:21:53 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Subject: [SIP] not very clear about sip encryption
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

hi all,
     i'm a novice among u all and have a query regarding the Encryption 
header. Its regarding the public key as to where it would be stored and how 
the individuals will convey there public keys to each other and which of the 
SIP protocol entities should act as the trustworthy one who signes the 
public key.
   In the rfc it is mentioned that a sip client will isssue a message to the 
server with encrypted with the others public key, i am puzzled as to how it 
will get to know the others public keys. Please send me information from the 
implementation point of view since i sincerely want to inclue this facility 
in my SIP stack. Waiting for a prompt reply.
       bye,
          rahul
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.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 Jul 18 10:38:15 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25648
	for ; Tue, 18 Jul 2000 10:38:15 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4CBAD443C8; Tue, 18 Jul 2000 10:37:35 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id BBF2B44373
	for ; Tue, 18 Jul 2000 10:37:30 -0400 (EDT)
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA14356; Tue, 18 Jul 2000 15:34:54 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Henning Schulzrinne ,
        "Fairlie-Cuninghame, Robert" 
Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
Date: Tue, 18 Jul 2000 15:15:15 +0100
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
Cc: sip@lists.bell-labs.com
References:  <39744C3C.A2A6808F@cs.columbia.edu>
In-Reply-To: <39744C3C.A2A6808F@cs.columbia.edu>
MIME-Version: 1.0
Message-Id: <00071815310802.09459@gethin>
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

So can i just confirm with a couple of possible torture test examples
and what they should resolve to:

(1) sip:ABCD;a=b@host

user = "ABCD;a=b"
host = "host"

(2) sip:ABCD;a=b@host1;c=d@host2

user = "ABCD;a=b" 
host = "host1"
sip parameter = "c=d@host2"

(3) sip:ABCD;a=b%40host

user = ""
host = "ABCD"
sip parameter = "a=b@host"

(4) sip:ABCD;a=b%40host1;c=d@host2

user = "ABCD;a=b@host1;c=d"
host = "host2"


Is there any element of this that these examples do not cover?

-- 
Gethin Liddell
Ubiquity Software Corporation

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 10:39:31 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26276
	for ; Tue, 18 Jul 2000 10:39:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 100D5443D1; Tue, 18 Jul 2000 10:38:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 6D4F1443CD
	for ; Tue, 18 Jul 2000 10:38:32 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA09623;
	Tue, 18 Jul 2000 10:39:47 -0400 (EDT)
Message-ID: <39746CAF.926E080D@dynamicsoft.com>
Date: Tue, 18 Jul 2000 10:41:51 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
Cc: "Fairlie-Cuninghame, Robert" ,
        "'Gethin Liddell'" , sip@lists.bell-labs.com
Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
References:  <39744C3C.A2A6808F@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:
> 
> Since the top-level structure is "sip: userinfo @ hostport". Thus, split
> the URL into the "pre-@" and "post-@" parts. Parse each independently.
> 
> However, I agree that given that the 'userinfo @' is optional,
> suggesting escaping of @ is probably wise.

Well, I would make a stronger statement than "suggest". Sounds like we
should
mandate that @ be escaped anywhere within the URL.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 10:45:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29019
	for ; Tue, 18 Jul 2000 10:45:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 19B3D443CC; Tue, 18 Jul 2000 10:45:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CBB6F443A5
	for ; Tue, 18 Jul 2000 10:44:58 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA09671;
	Tue, 18 Jul 2000 10:46:25 -0400 (EDT)
Message-ID: <39746E3D.F5ED5844@dynamicsoft.com>
Date: Tue, 18 Jul 2000 10:48:29 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Daiker 
Cc: Jo Hornsby , Kim Liu ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] A question about Stateful Proxies, Session Timers, and the
References: <200007171354.JAA08894@blanc.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



David Daiker wrote:
> 
> Jonathan, actually I think it *could* be done. Just like 'via' encryption, btw,
> with the exception that on responses the downstream route is encrypted,
> not popped. That way the caller sees only the 1st (record-route) downstream
> proxy in the clear, and the callee sees only the final one.

The record-route in the responses will have already been encrypted,
since the response reflects the request, which was encrypted in the
forward direction....

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 10:58:07 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05307
	for ; Tue, 18 Jul 2000 10:58:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E6EA944357; Tue, 18 Jul 2000 10:57:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from seattle.3com.com (seattle.3com.com [129.213.128.97])
	by lists.bell-labs.com (Postfix) with ESMTP id 7966E44336
	for ; Tue, 18 Jul 2000 10:57:36 -0400 (EDT)
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12])
	by seattle.3com.com (8.8.8/8.8.8) with ESMTP id HAA18390
	for ; Tue, 18 Jul 2000 07:57:35 -0700 (PDT)
From: Anoop_Tripathi@3com.com
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by new-york.3com.com (8.8.8/8.8.8) with SMTP id HAA08876
	for ; Tue, 18 Jul 2000 07:57:10 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256920.00521A35 ; Tue, 18 Jul 2000 07:56:46 -0700
X-Lotus-FromDomain: 3COM
To: sip@lists.bell-labs.com
Message-ID: <88256920.005218A9.00@hqoutbound.ops.3com.com>
Date: Tue, 18 Jul 2000 09:55:56 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Questions on new loop detection mentioned in RFC2543 bis
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com




I have some questions on how we distinguish the BYE and CANCEL messages for a
call in case a proxy is now twice in the path of the same call. ( Note:In RFC
2543 bis with the new loop detection mechanism it is now possible for a Proxy to
be present twice in the path of the same call if the Request-URI is different.)

Assuming that a proxy P2 is now twice in the path of the call.

The scenario is as follows


A---------------P1------------P2----------P3----------P2---------P4----------B.


I assume that P2 would treat them as two different calls.

1)  P1-----P2------P3

2) P3-----P2------P4



Q1)  Now when a CANCEL message comes to P2, the only way it can find out whether
it is from P1 or P3 is if the Request-URI in CANCEL IS SAME AS IN      INVITE.
Are we guaranteed to have the Request-URI in these two messages the same?

Q2)  If P2 is call stateful, then it needs to put some additonal tags in the
Record-Route header, similar to hash values it has put in Via header to
distinguish BYE     messages?

Q3)         Can a call leg still be identified with CallID, From and To headers
or we need one extra identifier ( probably a hash similar to one in Via) ?


Thanks,

Anoop Tripathi

3COM




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


From sip-admin@lists.bell-labs.com  Tue Jul 18 11:18:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14747
	for ; Tue, 18 Jul 2000 11:18:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 83B67443B0; Tue, 18 Jul 2000 11:17:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from 192.116.213.130 (unknown [192.116.213.130])
	by lists.bell-labs.com (Postfix) with SMTP id 7B3C244373
	for ; Tue, 18 Jul 2000 11:17:30 -0400 (EDT)
Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by 192.116.213.130 ; Tue, 18 Jul 2000 18:11:33 -0700
Received: by NT-MAIL with Internet Mail Service (5.5.2650.21)
	id ; Tue, 18 Jul 2000 18:15:55 +0300
Message-ID: 
From: Itamar Gilad 
To: "'Jonathan Rosenberg'" ,
        "'SIP List'" 
Subject: RE: [SIP] Multiple sessions in SDP payload
Date: Tue, 18 Jul 2000 18:15:55 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tue, July 18, 2000 5:17 PM
> To: Christian Huitema
> Cc: 'William Lee'; 'Philip Levis'; sip@lists.bell-labs.com
> Subject: Re: [SIP] Multiple sessions in SDP payload
> 
> 
> 
> Christian Huitema wrote:
> > The problem is, there is a fundamental contradiction 
> between two requirements. If I include 3 "m=audio" lines, do 
> they describe
> > 3 ways to pass audio, such as IPv4, IPv6 and POTS, or do I 
> describe 3 audio channels that should be deployed in parallel? My
> > take so far would be to use multiple instance of the same 
> media within a single SDP payload to describe alternative encodings,
> > and to use multiple SDP payloads, using MIME multipart, to 
> encode several parallel sessions.
> 
> I think three lines of the same type means the same thing it does in
> SAPs usage - parallel media streams, not alternatives. This, 
> in fact, is
> necessary as per the other thread on sending DTMF using 
> rfc2833 to third
> party application servers.
> 
> 
> As for multiple sessions per SDP, I don't know what the value of this
> would be. rfc2543 is silent on this, and I would suggest it be
> disallowed within SIP.
> 
> -Jonathan R.

I agree. RFC 2543 1.3 defines Call and Session as follows:

        Call: A call consists of all participants in a conference
             invited by a common source. A SIP call is identified by a
             globally unique call-id (Section 6.13)...

        Session: From the SDP specification: "A multimedia session is a
             set of multimedia senders and receivers and the data
             streams flowing from senders to receivers. A multimedia
             conference is an example of a multimedia session." (RFC
             2327 [6]) (A session as defined for SDP can comprise one or
             more RTP sessions.) As defined, a callee can be invited
             several times, by different calls, to the same session. If
             SDP is used, a session is defined by the concatenation of
             the user name , session id , network type , address type
             and address elements in the origin field.

This I believe implies that a SIP Call and a SDP session have a one-to-one
relationship identified by the Call-ID in SIP and the (single) o= line in
the SDP session section.
 
 Itamar

> 
> >        -----Original Message-----
> >        From: William Lee [mailto:williaml@nortelnetworks.com]
> >        Sent: Monday, July 17, 2000 10:15 PM
> >        To: 'Philip Levis'
> >        Cc: sip@lists.bell-labs.com
> >        Subject: RE: [SIP] Multiple sessions in SDP payload
> > 
> >        Yes, according to the spec, multiple SDP sessions 
> may be specified.  
> >        At the 2nd SIP bake-off, we tested a trial 
> implementation of our 
> >        SDP parser/statemachine that sent and received 
> multiple SDP sessions. 
> >        No one supported this, and as far as I know no one 
> else does today. 
> 
> 
> 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 11:28:21 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19968
	for ; Tue, 18 Jul 2000 11:28:21 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 28731443B7; Tue, 18 Jul 2000 11:28:16 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from nago.cs.colorado.edu (nago.cs.colorado.edu [128.138.202.19])
	by lists.bell-labs.com (Postfix) with ESMTP id 37D114435F
	for ; Tue, 18 Jul 2000 11:28:08 -0400 (EDT)
Received: from imix.cs.colorado.edu (imix.cs.colorado.edu [128.138.202.190])
	by nago.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6IFS4X22266
	for ; Tue, 18 Jul 2000 09:28:04 -0600 (MDT)
Received: from localhost (levis@localhost)
	by imix.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6IFS4v23012
	for ; Tue, 18 Jul 2000 09:28:04 -0600 (MDT)
X-Authentication-Warning: imix.cs.colorado.edu: levis owned process doing -bs
Date: Tue, 18 Jul 2000 09:28:04 -0600 (MDT)
From: Philip Levis 
To: sip@lists.bell-labs.com
Subject: Re: [SIP] Multiple sessions in SDP payload
In-Reply-To: <397466C2.42AFFAC@dynamicsoft.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

On Tue, 18 Jul 2000, Jonathan Rosenberg wrote:

> As for multiple sessions per SDP, I don't know what the value of this
> would be. rfc2543 is silent on this, and I would suggest it be
> disallowed within SIP.

There is a simple value; it provides additional information at little
cost.

In short, it allows for an explicit distinction to be made between
multiple streams, and multiple options for a stream. There's a very
pronounced (and useful) difference between:

v=0
...
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
...

and
v=0
...
m=audio 49170 RTP/AVP 0
...
v=0
...
m=video 51372 RTP/AVP 31
...
v=0
...
m=application 32416 udp wb
...

It would allow a UA to make more intelligent decisions on what SDP to
reply with, if some codecs are more desirable than others (say, because of
hardware decoding).

Phil




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


From sip-admin@lists.bell-labs.com  Tue Jul 18 11:36:47 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23777
	for ; Tue, 18 Jul 2000 11:36:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DEF95443CB; Tue, 18 Jul 2000 11:36:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 922AE443C9
	for ; Tue, 18 Jul 2000 11:36:40 -0400 (EDT)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05977;
	Tue, 18 Jul 2000 08:36:52 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAA79022;
	Tue, 18 Jul 2000 08:36:38 -0700 (PDT)
Message-Id: <4.2.0.58.20000718082630.01c49d10@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 18 Jul 2000 08:35:52 -0700
To: Gethin Liddell 
From: Rohan Mahy 
Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
Cc: Henning Schulzrinne ,
        "Fairlie-Cuninghame, Robert" ,
        sip@lists.bell-labs.com
In-Reply-To: <00071815310802.09459@gethin>
References: <39744C3C.A2A6808F@cs.columbia.edu>
 
 <39744C3C.A2A6808F@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,

Why should folks be using (;) as a parameter delimeter in userpart when (,) 
is a perfectly fine alternative?  I'd say we should escape (;) and (@) in 
the userpart and in the parameters.

thanks,
-rohan

At 07:15 AM 7/18/00 , Gethin Liddell wrote:
>So can i just confirm with a couple of possible torture test examples
>and what they should resolve to:
>
>(1) sip:ABCD;a=b@host
>
>user = "ABCD;a=b"
>host = "host"
>
>(2) sip:ABCD;a=b@host1;c=d@host2
>
>user = "ABCD;a=b"
>host = "host1"
>sip parameter = "c=d@host2"
>
>(3) sip:ABCD;a=b%40host
>
>user = ""
>host = "ABCD"
>sip parameter = "a=b@host"
>
>(4) sip:ABCD;a=b%40host1;c=d@host2
>
>user = "ABCD;a=b@host1;c=d"
>host = "host2"
>
>
>Is there any element of this that these examples do not cover?
>
>--
>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  Tue Jul 18 11:44:47 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26587
	for ; Tue, 18 Jul 2000 11:44:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 00B7A443D5; Tue, 18 Jul 2000 11:41:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from nago.cs.colorado.edu (nago.cs.colorado.edu [128.138.202.19])
	by lists.bell-labs.com (Postfix) with ESMTP id 4480E44336
	for ; Tue, 18 Jul 2000 11:41:34 -0400 (EDT)
Received: from imix.cs.colorado.edu (imix.cs.colorado.edu [128.138.202.190])
	by nago.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6IFfXX22396;
	Tue, 18 Jul 2000 09:41:33 -0600 (MDT)
Received: from localhost (levis@localhost)
	by imix.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6IFfXv23030;
	Tue, 18 Jul 2000 09:41:33 -0600 (MDT)
X-Authentication-Warning: imix.cs.colorado.edu: levis owned process doing -bs
Date: Tue, 18 Jul 2000 09:41:32 -0600 (MDT)
From: Philip Levis 
To: Itamar Gilad 
Cc: "'Jonathan Rosenberg'" ,
        "'SIP List'" 
Subject: RE: [SIP] Multiple sessions in SDP payload
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

On Tue, 18 Jul 2000, Itamar Gilad wrote:

>         Session: From the SDP specification: "A multimedia session is a
>              set of multimedia senders and receivers and the data
>              streams flowing from senders to receivers. A multimedia
>              conference is an example of a multimedia session." (RFC
>              2327 [6]) (A session as defined for SDP can comprise one or
>              more RTP sessions.) As defined, a callee can be invited
>              several times, by different calls, to the same session. If
>              SDP is used, a session is defined by the concatenation of
>              the user name , session id , network type , address type
>              and address elements in the origin field.
> 
> This I believe implies that a SIP Call and a SDP session have a one-to-one
> relationship identified by the Call-ID in SIP and the (single) o= line in
> the SDP session section.

It may imply that, but I don't think it makes any sense.

2543bis:

"A Call consisists of all participants in a conference united by a common
source. A SIP call is identified by a globally unique Call-ID."

In 3pcc, there are multiple parties invited with different SDPs from one
source. Being from one source, each call leg may have the same Call-ID,
yet different SDPs. This is especially true in the case of a central media
server, in which parties may have different media capabilities.

Phil



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


From sip-admin@lists.bell-labs.com  Tue Jul 18 11:48:59 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28136
	for ; Tue, 18 Jul 2000 11:48:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8CFA6443D8; Tue, 18 Jul 2000 11:43:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 945C5443C2
	for ; Tue, 18 Jul 2000 11:43:29 -0400 (EDT)
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id QAA19979; Tue, 18 Jul 2000 16:41:05 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Rohan Mahy 
Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
Date: Tue, 18 Jul 2000 16:32:14 +0100
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
Cc: sip@lists.bell-labs.com
References: <39744C3C.A2A6808F@cs.columbia.edu> <4.2.0.58.20000718082630.01c49d10@lint.cisco.com>
In-Reply-To: <4.2.0.58.20000718082630.01c49d10@lint.cisco.com>
MIME-Version: 1.0
Message-Id: <00071816372000.10836@gethin>
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

On Tue, 18 Jul 2000, Rohan Mahy wrote:
> Hi,
> 
> Why should folks be using (;) as a parameter delimeter in userpart when (,) 
> is a perfectly fine alternative?  I'd say we should escape (;) and (@) in 
> the userpart and in the parameters.

because we are considering the case where the tel url (RFC 2806) is
used in the user part.  This uses ; as a parameter delimiter.

-- 
Gethin Liddell
Ubiquity Software Corporation

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 11:56:00 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01228
	for ; Tue, 18 Jul 2000 11:55:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D9507443D9; Tue, 18 Jul 2000 11:54:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from zrtps06s.us.nortel.com (unknown [47.140.48.50])
	by lists.bell-labs.com (Postfix) with ESMTP id 4FCC74435F
	for ; Tue, 18 Jul 2000 11:53:57 -0400 (EDT)
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Tue, 18 Jul 2000 11:49:43 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Tue, 18 Jul 2000 11:49:42 -0400
Message-ID: <28560036253BD41191A10000F8BCBD11480B8D@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Philip Levis'" , sip@lists.bell-labs.com
Subject: RE: [SIP] Multiple sessions in SDP payload
Date: Tue, 18 Jul 2000 11:49:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF0CF.C7A5C690"
X-Orig: 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF0CF.C7A5C690
Content-Type: text/plain

I strongly second this view, which we have incorporated into the Megaco
media negotiation rules in the belief that the call signalling protocol
would behave the same way.

> -----Original Message-----
> From:	Philip Levis [SMTP:levis@cs.colorado.edu]
> Sent:	Tuesday, July 18, 2000 11:28 AM
> To:	sip@lists.bell-labs.com
> Subject:	Re: [SIP] Multiple sessions in SDP payload
> 
> On Tue, 18 Jul 2000, Jonathan Rosenberg wrote:
> 
> > As for multiple sessions per SDP, I don't know what the value of this
> > would be. rfc2543 is silent on this, and I would suggest it be
> > disallowed within SIP.
> 
> There is a simple value; it provides additional information at little
> cost.
> 
> In short, it allows for an explicit distinction to be made between
> multiple streams, and multiple options for a stream. There's a very
> pronounced (and useful) difference between:
> 
> v=0
> ...
> m=audio 49170 RTP/AVP 0
> m=video 51372 RTP/AVP 31
> m=application 32416 udp wb
> ...
> 
> and
> v=0
> ...
> m=audio 49170 RTP/AVP 0
> ...
> v=0
> ...
> m=video 51372 RTP/AVP 31
> ...
> v=0
> ...
> m=application 32416 udp wb
> ...
> 
> It would allow a UA to make more intelligent decisions on what SDP to
> reply with, if some codecs are more desirable than others (say, because of
> hardware decoding).
> 
> Phil
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01BFF0CF.C7A5C690
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Multiple sessions in SDP payload




I strongly second =
this view, which we have incorporated into the Megaco media negotiation =
rules in the belief that the call signalling protocol would behave the =
same way.


    

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

    From:   Philip Levis =
[SMTP:levis@cs.colorado.edu]

    Sent:   Tuesday, July 18, 2000 11:28 AM

    To:     sip@lists.bell-labs.com

    Subject:       =
 Re: [SIP] Multiple sessions in SDP =
payload

    


    On Tue, 18 Jul 2000, Jonathan =
Rosenberg wrote:

    


    > As for multiple sessions per SDP, =
I don't know what the value of this

    > would be. rfc2543 is silent on =
this, and I would suggest it be

    > disallowed within SIP.

    


    There is a simple value; it provides =
additional information at little

    cost.

    


    In short, it allows for an explicit =
distinction to be made between

    multiple streams, and multiple =
options for a stream. There's a very

    pronounced (and useful) difference =
between:

    


    v=3D0

    ...

    m=3Daudio 49170 RTP/AVP 0

    m=3Dvideo 51372 RTP/AVP 31

    m=3Dapplication 32416 udp wb

    ...

    


    and

    v=3D0

    ...

    m=3Daudio 49170 RTP/AVP 0

    ...

    v=3D0

    ...

    m=3Dvideo 51372 RTP/AVP 31

    ...

    v=3D0

    ...

    m=3Dapplication 32416 udp wb

    ...

    


    It would allow a UA to make more =
intelligent decisions on what SDP to

    reply with, if some codecs are more =
desirable than others (say, because of

    hardware decoding).

    


    Phil

    

    

    

    


    _______________________________________________

    SIP mailing list

    SIP@lists.bell-labs.com

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

    




------_=_NextPart_001_01BFF0CF.C7A5C690--


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 11:58:58 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02733
	for ; Tue, 18 Jul 2000 11:58:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 650FD443DF; Tue, 18 Jul 2000 11:55:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id EE89E4437F
	for ; Tue, 18 Jul 2000 11:55:45 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA10263;
	Tue, 18 Jul 2000 11:56:49 -0400 (EDT)
Message-ID: <39747EBD.471B91FE@dynamicsoft.com>
Date: Tue, 18 Jul 2000 11:58:53 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Philip Levis 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Multiple sessions in SDP payload
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Philip Levis wrote:
> 
> On Tue, 18 Jul 2000, Jonathan Rosenberg wrote:
> 
> > As for multiple sessions per SDP, I don't know what the value of this
> > would be. rfc2543 is silent on this, and I would suggest it be
> > disallowed within SIP.
> 
> There is a simple value; it provides additional information at little
> cost.
> 
> In short, it allows for an explicit distinction to be made between
> multiple streams, and multiple options for a stream. There's a very
> pronounced (and useful) difference between:

Well, this isn't how it works.

Multiple media streams in SDP means exactly that, multiple media
streams. Thats the usage in SAP, thats been the usage for SIP. I don't
want to change this. If you want alternatives for the same stream, you
list multiple codecs on the same m line. Thats the defined usage.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 12:09:35 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07366
	for ; Tue, 18 Jul 2000 12:09:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 541DB443C8; Tue, 18 Jul 2000 12:07:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id CDCD244336
	for ; Tue, 18 Jul 2000 12:07:22 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id RAA21978; Tue, 18 Jul 2000 17:05:17 +0100 (BST)
From: "Jo Hornsby" 
To: , 
Subject: RE: [SIP] Questions on new loop detection mentioned in RFC2543 bis
Date: Tue, 18 Jul 2000 17:05:16 +0100
Message-ID: <003701bff0d1$f65463a0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <88256920.005218A9.00@hqoutbound.ops.3com.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> I have some questions on how we distinguish the BYE and CANCEL 
> messages for a call in case a proxy is now twice in the path
> of the same call. (Note:In RFC 2543 bis with the new loop
> detection mechanism it is now possible for a Proxy to be present
> twice in the path of the same call if the Request-URI is
> different.)
> 
> Assuming that a proxy P2 is now twice in the path of the call.
> 
> The scenario is as follows
> 
> 
> A---------------P1------------P2----/
> ------P3----------P2---------P4----------B.
> 
> 
> I assume that P2 would treat them as two different calls.
> 
> 1)  P1-----P2------P3
> 
> 2) P3-----P2------P4

Yup.  The requests are different because of the different
Request-URI.

> Q1)  Now when a CANCEL message comes to P2, the only way it can 
> find out whether it is from P1 or P3 is if the Request-URI in
> CANCEL IS SAME AS IN INVITE.
> Are we guaranteed to have the Request-URI in these two messages
> the same?

Yup.  I've lost it in the draft, though. &:(

> Q2)  If P2 is call stateful, then it needs to put some additonal 
> tags in the Record-Route header, similar to hash values it has
> put in Via header to distinguish BYE     messages?

Putting any sort of state or ID or whathaveyou in Record-Route
is no good because by the time a new request has arrived at
the offending proxy, the pertinent Route value has been popped.

But you have raised a very good point, I feel.  Since Record-Route
is defined to be (basically) name-addr plus an maddr parameter,
it is probably workable if clients copy the addr-spec component
of the topmost Route value into the Request-URI (which is what
they are supposed to do), and send it to the address specified
by the maddr parameter; _provided_ that a proxy copied the
Request-URI of the initial request into the Record-Route, and
added its own IP as the maddr parameter (not so sure this is
conforming -- I am a little confused by the second paragraph of
6.35.1 in the July bis).

This has a couple of problems, though:
 1) In the reverse direction; i.e., if UA1 initially called
    UA2 resulting in a spiral through a Proxy which added
    itself twice in the Record-Route, and then UA2 issues a
    re-INVITE to UA1; it (illegally) loops.  This is because of
    the rules about constructing the Route header in 6.35.2,
    which say that the Contact address of UA1 will be used as
    the name-addr part.
 2) Proxies are going to have to accept that Record-Routes
    need to go though port 5060 (or perhaps some other returned
    by SRV), since there is no way to specify otherwise with maddr.
    (This problem isn't restricted to this special case, however,
    since the "reverse" request path, for instance, exhibits
    the same problems.)

> Q3)         Can a call leg still be identified with CallID, From 
> and To headers or we need one extra identifier ( probably a hash
> similar to one in Via) ?

Well, I guess if you need to keep tabs on both parts of the spiral,
you could use the Request-URI.

I think the easiest solution is probably to just note that the
request has spiralled, and update state for the multiple interested
"parties" as necessary.  Is there any need for a proxy to add
itself more than once in a Record-Route?  There can still only be
one call leg, after all.

HTH,


 - Jo.



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


From sip-admin@lists.bell-labs.com  Tue Jul 18 12: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 ESMTP id MAA08287
	for ; Tue, 18 Jul 2000 12:11:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 801BD443E5; Tue, 18 Jul 2000 12:09:00 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from nago.cs.colorado.edu (nago.cs.colorado.edu [128.138.202.19])
	by lists.bell-labs.com (Postfix) with ESMTP id EA893443D2
	for ; Tue, 18 Jul 2000 12:08:51 -0400 (EDT)
Received: from imix.cs.colorado.edu (imix.cs.colorado.edu [128.138.202.190])
	by nago.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6IG8kX22707;
	Tue, 18 Jul 2000 10:08:47 -0600 (MDT)
Received: from localhost (levis@localhost)
	by imix.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id e6IG8k623074;
	Tue, 18 Jul 2000 10:08:46 -0600 (MDT)
X-Authentication-Warning: imix.cs.colorado.edu: levis owned process doing -bs
Date: Tue, 18 Jul 2000 10:08:46 -0600 (MDT)
From: Philip Levis 
To: Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Multiple sessions in SDP payload
In-Reply-To: <39747EBD.471B91FE@dynamicsoft.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

On Tue, 18 Jul 2000, Jonathan Rosenberg wrote:

> Well, this isn't how it works.
> 
> Multiple media streams in SDP means exactly that, multiple media
> streams. Thats the usage in SAP, thats been the usage for SIP. I don't
> want to change this. If you want alternatives for the same stream, you
> list multiple codecs on the same m line. Thats the defined usage.

You are correct. A closer reading of 2327 even states that the desired
functionality (preference) is already present in SDP:

"When a list of payload formats is given, this implies that all of
these formats may be used in the session, but the first of these
formats is the default format for the session." (pg. 20)

In light of this, I agree that that the presence of multiple SDP sessions
is not useful (at least, in any circumstance I can come up with).

Phil



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


From sip-admin@lists.bell-labs.com  Tue Jul 18 12:31:33 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17659
	for ; Tue, 18 Jul 2000 12:31:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 886C54439F; Tue, 18 Jul 2000 12:30:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from june.idc1.level3.com (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id B10E44435E
	for ; Tue, 18 Jul 2000 12:30:44 -0400 (EDT)
Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140])
	by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id QAA16422;
	Tue, 18 Jul 2000 16:30:43 GMT
From: Jon.Peterson@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id KAA04682;
	Tue, 18 Jul 2000 10:30:42 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 18 Jul 2000 10:32:25 -0600
Message-ID: <87A245E94948D3118DE30008C716B01301523A29@c0005v1idc1.oss.level3.com>
To: levis@cs.colorado.edu, jdrosen@dynamicsoft.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Multiple sessions in SDP payload
Date: Tue, 18 Jul 2000 10:30:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

From my perspective, it is highly desirable for each of the legs of a
multiparty 3pcc call to act like an individual, normal call, to the degree
that such is possible. Bundling session information for several legs into a
single INVITE, for example, makes it difficult for any application
intelligence in the network to govern the behavior of say, two out of five
legs; the closer the legs look to normal calls, the easier it is to reuse
infrastructure that manages normal calls to handle these more advanced
cases. I think this method also provides the greatest flexibility for both
the corrollation and differentiation of each of the legs.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Philip Levis [mailto:levis@cs.colorado.edu]
Sent: Tuesday, July 18, 2000 12:09 PM
To: Jonathan Rosenberg
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Multiple sessions in SDP payload


On Tue, 18 Jul 2000, Jonathan Rosenberg wrote:

> Well, this isn't how it works.
> 
> Multiple media streams in SDP means exactly that, multiple media
> streams. Thats the usage in SAP, thats been the usage for SIP. I don't
> want to change this. If you want alternatives for the same stream, you
> list multiple codecs on the same m line. Thats the defined usage.

You are correct. A closer reading of 2327 even states that the desired
functionality (preference) is already present in SDP:

"When a list of payload formats is given, this implies that all of
these formats may be used in the session, but the first of these
formats is the default format for the session." (pg. 20)

In light of this, I agree that that the presence of multiple SDP sessions
is not useful (at least, in any circumstance I can come up with).

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  Tue Jul 18 13:24: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 ESMTP id NAA11738
	for ; Tue, 18 Jul 2000 13:24:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AD1EA44338; Tue, 18 Jul 2000 13:24:32 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id DEED044336
	for ; Tue, 18 Jul 2000 13:24:29 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA10812;
	Tue, 18 Jul 2000 13:25:54 -0400 (EDT)
Message-ID: <3974939D.129CC05C@dynamicsoft.com>
Date: Tue, 18 Jul 2000 13:27:57 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rahul pande 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] not very clear about sip encryption
References: <20000718142153.99423.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



rahul pande wrote:
> 
> hi all,
>      i'm a novice among u all and have a query regarding the Encryption
> header. Its regarding the public key as to where it would be stored and how
> the individuals will convey there public keys to each other and which of the
> SIP protocol entities should act as the trustworthy one who signes the
> public key.

The PKI is independent and outside of SIP. 

Since we use PGP for encryption, typically the keys would exist already
on the PGP keyring of the user, stored locally. Who signs a given key,
in PGP, is anyone - so long as you have a path of signatures to a
trusted entity.
 
>    In the rfc it is mentioned that a sip client will isssue a message to the
> server with encrypted with the others public key, i am puzzled as to how it
> will get to know the others public keys.

For PGP, they are in the keyring stored locally.

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 13:30:58 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13951
	for ; Tue, 18 Jul 2000 13:30:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0AD944436C; Tue, 18 Jul 2000 13:30:54 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id E66C34435D
	for ; Tue, 18 Jul 2000 13:30:50 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA10843;
	Tue, 18 Jul 2000 13:28:28 -0400 (EDT)
Message-ID: <39749438.DA3341B6@dynamicsoft.com>
Date: Tue, 18 Jul 2000 13:30:32 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gethin Liddell 
Cc: Henning Schulzrinne ,
        "Fairlie-Cuninghame, Robert" ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
References:  <39744C3C.A2A6808F@cs.columbia.edu> <00071815310802.09459@gethin>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Gethin Liddell wrote:
> 
> So can i just confirm with a couple of possible torture test examples
> and what they should resolve to:
> 
> (1) sip:ABCD;a=b@host
> 
> user = "ABCD;a=b"
> host = "host"

yes.

> 
> (2) sip:ABCD;a=b@host1;c=d@host2
> 
> user = "ABCD;a=b"
> host = "host1"
> sip parameter = "c=d@host2"

In my previous note, I recommended that @ within parameters be escaped,
so that you wouldn't even see the second @.

> 
> (3) sip:ABCD;a=b%40host
> 
> user = ""
> host = "ABCD"
> sip parameter = "a=b@host"

yes.

> 
> (4) sip:ABCD;a=b%40host1;c=d@host2
> 
> user = "ABCD;a=b@host1;c=d"
> host = "host2"

yes.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 13:39:46 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17123
	for ; Tue, 18 Jul 2000 13:39:45 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 19C5544338; Tue, 18 Jul 2000 13:39:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 204CF44336
	for ; Tue, 18 Jul 2000 13:38:58 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA10880;
	Tue, 18 Jul 2000 13:36:39 -0400 (EDT)
Message-ID: <39749622.D8E0F2DD@dynamicsoft.com>
Date: Tue, 18 Jul 2000 13:38:42 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
Cc: "'Jo Hornsby'" , sip@lists.bell-labs.com
Subject: Re: [SIP] Contact in final INVITE response.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Fairlie-Cuninghame, Robert" wrote:
> 
> Jo,
> 
> Forgive me, I wrote the statement backwards, I meant to say a number of
> people were sending INVITE error responses from ports they were not
> expecting the ACK to be sent to. [The ACK is sort of a response to the
> response.] This is perfectly legal.
> 
> The received response will have a Via field that only has your own IP
> address/hostname in it (which is of not use in routing the ACK).
> 
> You seem to have worked out what I meant anyway. [Thank-you]
> 
> Yes the bis says something about error-information in 4xx,5xx,6xx but I
> don't think this is necessarily mutually exclusive with putting a sip: URL
> in there for ACK routing (as for 2xx). I don't think that a SIP URL
> providing error-information for a SIP error is a good thing (although I'm
> sure we can find some people to disagree).

Let me summarize what you are trying to say here:

1. a server sends a 4xx response
2. the UAC or proxy now needs to send an ACK
3. the 4xx response was sent with a source port the server is not
listening on
4. the ACK will not be received by the server

I don't see why 4. follows, if that is what you are claiming. The ACK
should be sent to the same address and port you sent the INVITE to.
Obviously the server is listening there or it wouldn't have gotten the
INVITE in the first place. So, the ACK will be received by the server.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 14:16:20 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29376
	for ; Tue, 18 Jul 2000 14:16:19 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E02924435F; Tue, 18 Jul 2000 14:15:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id 2AA9644336
	for ; Tue, 18 Jul 2000 14:15:49 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7J1XZP>; Tue, 18 Jul 2000 11:16:12 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Jonathan Rosenberg'" 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Contact in final INVITE response.
Date: Tue, 18 Jul 2000 11:16:11 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

> 
> Let me summarize what you are trying to say here:
> 
> 1. a server sends a 4xx response
> 2. the UAC or proxy now needs to send an ACK
> 3. the 4xx response was sent with a source port the server is not
> listening on
> 4. the ACK will not be received by the server
> 
> I don't see why 4. follows, if that is what you are claiming. The ACK
> should be sent to the same address and port you sent the INVITE to.
> Obviously the server is listening there or it wouldn't have gotten the
> INVITE in the first place. So, the ACK will be received by the server.
> 
Thanks for the reply.

Sure, this is not a problem in the normal call flows (when you have that
information - ie, when you have cached state for the transaction) but there
is no way to respond to an error response you receive when you have no
cached transaction information.
Possible causes:
- Client crashes
- Client error which causes call state to be flushed (prehaps during to
handling of reinvite or CANCEL).
- Client does not cache original requests (for very long) after first ACK to
final response has been sent. [This is probably the most likely reason in
the field.] 

Admittedly, most of these cases result from implementation shortcuts (or
errors) but regardless of the cause, wouldn't it be more tidy from a
protocol point of view (in my mind) to be able to ACK to an error response
even when you don't have cached state for it. I think this should at the
very least to be "A sip URL MAY be added to Contact header of 4xx+ responses
(except for the pesky 485) to which the ACK should be sent"  - if not a
SHOULD or MUST.

Robert.

-- My opinions are my own. I tried selling them but everybody else 
	already seems to 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 Jul 18 14:54:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15606
	for ; Tue, 18 Jul 2000 14:54:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E04CF4437E; Tue, 18 Jul 2000 14:54:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by lists.bell-labs.com (Postfix) with SMTP id D45534435D
	for ; Tue, 18 Jul 2000 14:54:33 -0400 (EDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Jul 2000 11:54:16 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58)
	id ; Tue, 18 Jul 2000 11:54:15 -0700
Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C31B2@red-msg-24.redmond.corp.microsoft.com>
From: Christian Huitema 
To: "'Jonathan Rosenberg'" 
Cc: "'William Lee'" ,
        "'Philip Levis'" , sip@lists.bell-labs.com
Subject: RE: [SIP] Multiple sessions in SDP payload
Date: Tue, 18 Jul 2000 11:53:39 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Jonathan,

Suppose a station wants to encode its desire to support both RTP over IPv6
and RTP over IPv4. Due to various constraints, it cannot use the same
listening UDP port for IPv4 and IPv6. In the current definition of SDP, the
port number is encoded as the token immediately following the media type in
the "m=" line, and the address type is encoded on a "c=" line. How can I
possibly encode the SDP without having two media lines?

Christian Huitema

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, July 18, 2000 7:17 AM
> To: Christian Huitema
> Cc: 'William Lee'; 'Philip Levis'; sip@lists.bell-labs.com
> Subject: Re: [SIP] Multiple sessions in SDP payload
> 
> 
> 
> Christian Huitema wrote:
> > The problem is, there is a fundamental contradiction 
> between two requirements. If I include 3 "m=audio" lines, do 
> they describe
> > 3 ways to pass audio, such as IPv4, IPv6 and POTS, or do I 
> describe 3 audio channels that should be deployed in parallel? My
> > take so far would be to use multiple instance of the same 
> media within a single SDP payload to describe alternative encodings,
> > and to use multiple SDP payloads, using MIME multipart, to 
> encode several parallel sessions.
> 
> I think three lines of the same type means the same thing it does in
> SAPs usage - parallel media streams, not alternatives. This, 
> in fact, is
> necessary as per the other thread on sending DTMF using 
> rfc2833 to third
> party application servers.
> 
> 
> As for multiple sessions per SDP, I don't know what the value of this
> would be. rfc2543 is silent on this, and I would suggest it be
> disallowed within SIP.
> 
> -Jonathan R.
> 
> >        -----Original Message-----
> >        From: William Lee [mailto:williaml@nortelnetworks.com]
> >        Sent: Monday, July 17, 2000 10:15 PM
> >        To: 'Philip Levis'
> >        Cc: sip@lists.bell-labs.com
> >        Subject: RE: [SIP] Multiple sessions in SDP payload
> > 
> >        Yes, according to the spec, multiple SDP sessions 
> may be specified.  
> >        At the 2nd SIP bake-off, we tested a trial 
> implementation of our 
> >        SDP parser/statemachine that sent and received 
> multiple SDP sessions. 
> >        No one supported this, and as far as I know no one 
> else does today. 
> 
> 
> 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 15:03:36 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20739
	for ; Tue, 18 Jul 2000 15:03:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7AE63443A2; Tue, 18 Jul 2000 15:01:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from seattle.3com.com (seattle.3com.com [129.213.128.97])
	by lists.bell-labs.com (Postfix) with ESMTP id 2383144338
	for ; Tue, 18 Jul 2000 15:01:31 -0400 (EDT)
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12])
	by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA17103;
	Tue, 18 Jul 2000 12:01:29 -0700 (PDT)
From: Anoop_Tripathi@3com.com
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by new-york.3com.com (8.8.8/8.8.8) with SMTP id MAA06663;
	Tue, 18 Jul 2000 12:01:02 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256920.00686CB8 ; Tue, 18 Jul 2000 12:00:35 -0700
X-Lotus-FromDomain: 3COM
To: "Jo Hornsby" 
Cc: sip@lists.bell-labs.com
Message-ID: <88256920.00686B76.00@hqoutbound.ops.3com.com>
Date: Tue, 18 Jul 2000 13:59:42 -0500
Subject: RE: [SIP] Questions on new loop detection mentioned in RFC2543 bis
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com




My comments with >>>>




"Jo Hornsby"  on 07/18/2000 11:05:16 AM

Sent by:  "Jo Hornsby" 


To:   Anoop Tripathi/MW/US/3Com, sip@lists.bell-labs.com
cc:
Subject:  RE: [SIP] Questions on new loop detection mentioned in RFC2543 bis



> I have some questions on how we distinguish the BYE and CANCEL
> messages for a call in case a proxy is now twice in the path
> of the same call. (Note:In RFC 2543 bis with the new loop
> detection mechanism it is now possible for a Proxy to be present
> twice in the path of the same call if the Request-URI is
> different.)
>
> Assuming that a proxy P2 is now twice in the path of the call.
>
> The scenario is as follows
>
>
> A---------------P1------------P2----/
> ------P3----------P2---------P4----------B.
>
>
> I assume that P2 would treat them as two different calls.
>
> 1)  P1-----P2------P3
>
> 2) P3-----P2------P4

Yup.  The requests are different because of the different
Request-URI.

> Q1)  Now when a CANCEL message comes to P2, the only way it can
> find out whether it is from P1 or P3 is if the Request-URI in
> CANCEL IS SAME AS IN INVITE.
> Are we guaranteed to have the Request-URI in these two messages
> the same?

Yup.  I've lost it in the draft, though. &:(

> Q2)  If P2 is call stateful, then it needs to put some additonal
> tags in the Record-Route header, similar to hash values it has
> put in Via header to distinguish BYE     messages?

Putting any sort of state or ID or whathaveyou in Record-Route
is no good because by the time a new request has arrived at
the offending proxy, the pertinent Route value has been popped.

But you have raised a very good point, I feel.  Since Record-Route
is defined to be (basically) name-addr plus an maddr parameter,
it is probably workable if clients copy the addr-spec component
of the topmost Route value into the Request-URI (which is what
they are supposed to do), and send it to the address specified
by the maddr parameter; _provided_ that a proxy copied the
Request-URI of the initial request into the Record-Route, and
added its own IP as the maddr parameter (not so sure this is
conforming -- I am a little confused by the second paragraph of
6.35.1 in the July bis).

This has a couple of problems, though:
 1) In the reverse direction; i.e., if UA1 initially called
    UA2 resulting in a spiral through a Proxy which added
    itself twice in the Record-Route, and then UA2 issues a
    re-INVITE to UA1; it (illegally) loops.  This is because of
    the rules about constructing the Route header in 6.35.2,
    which say that the Contact address of UA1 will be used as
    the name-addr part.
 2) Proxies are going to have to accept that Record-Routes
    need to go though port 5060 (or perhaps some other returned
    by SRV), since there is no way to specify otherwise with maddr.
    (This problem isn't restricted to this special case, however,
    since the "reverse" request path, for instance, exhibits
    the same problems.)

> Q3)         Can a call leg still be identified with CallID, From
> and To headers or we need one extra identifier ( probably a hash
> similar to one in Via) ?

Well, I guess if you need to keep tabs on both parts of the spiral,
you could use the Request-URI.
>>>> How does it route the BYE from the called party. What should a Request URI
from B contain?
I think the easiest solution is probably to just note that the
request has spiralled, and update state for the multiple interested
"parties" as necessary.  Is there any need for a proxy to add
itself more than once in a Record-Route?  There can still only be
one call leg, after all.
>>>> We cannot assume that because to add to it P3 could have forked the
request. So while P2 sent out one
>>>> to P3, P3 forked it and now P2 is in the path a forked request. Hence we
cannot assume one call leg.
>>>>> The bottom line is CallID, From and To alone are not sufficient  to
identify a call leg once we >>>>> allow this new loop detection
HTH,


 - Jo.



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






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


From sip-admin@lists.bell-labs.com  Tue Jul 18 15:28:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03266
	for ; Tue, 18 Jul 2000 15:28:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3B9A544338; Tue, 18 Jul 2000 15:28:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 1412F44336
	for ; Tue, 18 Jul 2000 15:27:59 -0400 (EDT)
Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T6TLRX4>; Tue, 18 Jul 2000 12:27:44 -0700
Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8B73@sd_exchange.nuera.com>
From: "Fox, Mike" 
To: Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] How to stop a Lawnmower Man attack?
Date: Tue, 18 Jul 2000 12:27:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

> -----Original Message-----
> Jonathan Rosenberg wrote:
> "Fox, Mike" wrote:
> > 
> > The zombie never belongs to the attacker it belongs to some other
> > unsuspecting dupe so is can be very hard (impossible?) to 
> find who to
> > prosecute later.
> 
> In this case, how are you controlling it to make it make all those
> random phone calls?

Using software of course ;-). How did it get to the zombie, you ask.
Perhaps somebody read an email. Here is a clipping of a recent SANS alert.

From: Alan Paller for SANS NewsBites and SANS Windows Security Digest
      Services

I am forwarding this note to you as a FLASH because the vulnerability
it describes is probably the most dangerous programming error in Windows
workstation (all varieties -- 95, 98, 2000, NT 4.0) that Microsoft has
made.

You are vulnerable to total compromise simply by previewing or reading
an email (without opening any attachments) if you have one of the
affected operating systems and have the following installed:
* Microsoft Access 97 or 2000
* Internet Explorer 4.0 or higher, including 5.5 (Windows 2000 includes
  IE 5)
....

> 
> > 
> > Not that it has been widely implemented, a GK can be used 
> in conjunction
> > with a firewall so that only GK routed calls can be 
> originated or accepted
> > by a Zone. The administrative problem of protecting a few 
> GKs and a Firewall
> > seems more tractable than protecting all possible terminals.
> 
> You can certainly do this for SIP also; see:
> http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip
>-firewalls-00.txt
>
>Using firewalls though to prevent people from getting out is ultimateily
>futile.

Perhaps, but the point is not to reduce the service users have access to but
increase and improve them. Administrative domains which enable better
services can be considered. Users on administrative islands do not get as
good visibility into what is happening on the network. For example, I do not
want to be part of a prank I would like my service provider to recognize the
signature of pranks and stop them. If my UAC is behaving badly because it
got some virus I want it stopped. Most "users" do not want to be
administrators, and recognize the benefits of the administrative function.
Perhaps I'm wrong but it seems that many SIP endorsers have ideologically
eschew the concept of administrative control, but it can be useful. 

I would like to be clear in that I'm not trying to suggest that SIP does
support administrative control. Instead I would like to suggest that such
models are possible, and that a community effort in addressing security
threats could yield useful results.

Mike


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 15:46:28 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12151
	for ; Tue, 18 Jul 2000 15:46:28 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BD11E4439C; Tue, 18 Jul 2000 15:46:24 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 46BFF4435E
	for ; Tue, 18 Jul 2000 15:46:21 -0400 (EDT)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA08263;
	Tue, 18 Jul 2000 12:46:35 -0700 (PDT)
Received: from buckthorn-nt (dhcp-171-69-93-65.cisco.com [171.69.93.65])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAA82396;
	Tue, 18 Jul 2000 12:46:18 -0700 (PDT)
Message-Id: <4.2.0.58.20000718124402.00c943e0@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 18 Jul 2000 12:44:48 -0700
To: Gethin Liddell 
From: Rohan Mahy 
Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
Cc: sip@lists.bell-labs.com
In-Reply-To: <00071816372000.10836@gethin>
References: <4.2.0.58.20000718082630.01c49d10@lint.cisco.com>
 <39744C3C.A2A6808F@cs.columbia.edu>
 <4.2.0.58.20000718082630.01c49d10@lint.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

At 08:32 AM 7/18/00 , Gethin Liddell wrote:
>On Tue, 18 Jul 2000, Rohan Mahy wrote:
> > Hi,
> >
> > Why should folks be using (;) as a parameter delimeter in userpart when 
> (,)
> > is a perfectly fine alternative?  I'd say we should escape (;) and (@) in
> > the userpart and in the parameters.
>
>because we are considering the case where the tel url (RFC 2806) is
>used in the user part.  This uses ; as a parameter delimiter.

Why not just translate the (;)s to (,)s or escape the (;)s?

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  Tue Jul 18 15:52:00 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14613
	for ; Tue, 18 Jul 2000 15:52:00 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AAC5F44338; Tue, 18 Jul 2000 15:51:55 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by lists.bell-labs.com (Postfix) with SMTP id 7543F44336
	for ; Tue, 18 Jul 2000 15:51:52 -0400 (EDT)
Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Jul 2000 12:51:41 -0700 (Pacific Daylight Time)
Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58)
	id ; Tue, 18 Jul 2000 12:51:39 -0700
Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C31B6@red-msg-24.redmond.corp.microsoft.com>
From: Christian Huitema 
To: "'Fox, Mike'" ,
        Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] How to stop a Lawnmower Man attack?
Date: Tue, 18 Jul 2000 12:50:56 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

The basic line of defense against DoS attacks is to avoid "packet
multipliers," transactions in which the attacker sends M packets to a 3rd
party, in order to have the 3rd party send N packets to the target. If M=N, then
the attacker would have caused more trouble by just sending packets to the
target.

As Mike outlines, out of band signalling mechanism can be used to launch
these attacks. The transaction, for each channel, asks the 3rd party to
"send packets to address X." The problem is compounded in the case of
SIP/SDP by two factors:
1) one can list multiple media lines in a single call, triggering a
multiplication from 1 SDP packet to N media initiations,
2) RTP only includes a very slow handshake mechanism, so that a station can
well start sending many packets before noticing the lack of RTCP in return.
SIP provides a first line of defense through its 3 ways handshake and its
authentication mechanisms. One can record the source of the prank; just
compromising a station may not be enough if the authentication requires
real-time input of some form of secret. In any case, the instrument of the
attack will be dutifully logged, which does provide some possibility of
recourse.

The second line of defense has to be the SIP stacks of the 3rd parties. The
problem here is that sending the media stream to a different address than
the signalling packets ought to be perfectly OK -- I may want to transfer a
call leg, I may want to send the phone call to my stereo box. So one should
not reject a call merely because it involves a different media address.
OTOH, one could turn to a chatty version of the dialogue, to ensure that
there is at least one packet exchanged for each of the media, thus enforcing
M>=N.



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


From sip-admin@lists.bell-labs.com  Tue Jul 18 21:33:49 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26457
	for ; Tue, 18 Jul 2000 21:33:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1D7314435B; Tue, 18 Jul 2000 21:33:32 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157])
	by lists.bell-labs.com (Postfix) with ESMTP id E38F844336
	for ; Tue, 18 Jul 2000 21:33:26 -0400 (EDT)
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id VAA16180;
	Tue, 18 Jul 2000 21:33:16 -0400 (EDT)
Message-ID: <3975055E.5E97826@cs.columbia.edu>
Date: Tue, 18 Jul 2000 21:33:18 -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: Rohan Mahy , sip@lists.bell-labs.com
Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
References: <4.2.0.58.20000718082630.01c49d10@lint.cisco.com>
	 <39744C3C.A2A6808F@cs.columbia.edu>
	 <4.2.0.58.20000718082630.01c49d10@lint.cisco.com> <4.2.0.58.20000718124402.00c943e0@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


> 
> Why not just translate the (;)s to (,)s or escape the (;)s?

We had this discussion a few weeks ago . Escaping ; doesn't work since
then you can't distinguish semicolons that were escaped to begin with
and the syntactically significant semicolons. Translation to some other
character doesn't work well because you now have cascading translations.
It's also extremely ugly and done by no other URL scheme. I still don't
see the problem these kludges are supposed to solve.


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


From sip-admin@lists.bell-labs.com  Tue Jul 18 23:39:37 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03066
	for ; Tue, 18 Jul 2000 23:39:37 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9621A44338; Tue, 18 Jul 2000 23:39:30 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from june.idc1.level3.com (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 5147D44336
	for ; Tue, 18 Jul 2000 23:39:27 -0400 (EDT)
Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140])
	by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id DAA27934
	for ; Wed, 19 Jul 2000 03:39:26 GMT
From: Jon.Peterson@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id VAA04004
	for ; Tue, 18 Jul 2000 21:39:25 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 18 Jul 2000 21:41:08 -0600
Message-ID: <87A245E94948D3118DE30008C716B01301523A2C@c0005v1idc1.oss.level3.com>
To: sip@lists.bell-labs.com
Date: Tue, 18 Jul 2000 21:39:17 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Internet-Draft on SIP Application-layer Firewall Policies
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


There is a new Internet-Draft available at the URL below describing
SIP-related application-layer policies enforced at network edges (most
likely adjacent to firewalls):

http://www.ietf.org/internet-drafts/draft-jfp-sipfw-policy-00.txt

Comments are very welcome.

Jon Peterson
Level(3) Communications


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


From sip-admin@lists.bell-labs.com  Wed Jul 19 00: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 ESMTP id AAA21600
	for ; Wed, 19 Jul 2000 00:43:45 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A7B4744338; Wed, 19 Jul 2000 00:43:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CBF5F44336
	for ; Wed, 19 Jul 2000 00:43:33 -0400 (EDT)
Received: from dynamicsoft.com (1Cust119.tnt7.bos2.da.uu.net [63.27.144.119])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA14764;
	Wed, 19 Jul 2000 00:45:04 -0400 (EDT)
Message-ID: <397532CE.D818F90F@dynamicsoft.com>
Date: Wed, 19 Jul 2000 00:47:10 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fox, Mike" 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] How to stop a Lawnmower Man attack?
References: <613A6A6A3F09D3118F5C00508B2C24FEAD8B73@sd_exchange.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Fox, Mike" wrote:
> 

> >Using firewalls though to prevent people from getting out is ultimateily
> >futile.
> 
> Perhaps, but the point is not to reduce the service users have access to but
> increase and improve them. Administrative domains which enable better
> services can be considered. Users on administrative islands do not get as
> good visibility into what is happening on the network. For example, I do not
> want to be part of a prank I would like my service provider to recognize the
> signature of pranks and stop them. If my UAC is behaving badly because it
> got some virus I want it stopped. Most "users" do not want to be
> administrators, and recognize the benefits of the administrative function.
> Perhaps I'm wrong but it seems that many SIP endorsers have ideologically
> eschew the concept of administrative control, but it can be useful.
> 
> I would like to be clear in that I'm not trying to suggest that SIP does
> support administrative control. Instead I would like to suggest that such
> models are possible, and that a community effort in addressing security
> threats could yield useful results.

Mechanisms to prevent infected/misbehaving UAs from launching lots of
calls in order to perform a DoS attack are possible without any protocol
support. They all fall into the realm of policy of a server. When it
gets an INVITE, what to do? It can reject the request, if it likes, or
proxy, or redirect, or whatever. If you want to implement counters, and
if the same UA makes more than X calls in Y seconds, reject further
calls, thats just fine.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 19 00:55:39 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24849
	for ; Wed, 19 Jul 2000 00:55:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C4CA144396; Wed, 19 Jul 2000 00:55:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5B74A4433B
	for ; Wed, 19 Jul 2000 00:54:58 -0400 (EDT)
Received: from dynamicsoft.com (1Cust119.tnt7.bos2.da.uu.net [63.27.144.119])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA14780;
	Wed, 19 Jul 2000 00:55:53 -0400 (EDT)
Message-ID: <39753557.D75BBFCF@dynamicsoft.com>
Date: Wed, 19 Jul 2000 00:57:59 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: discussion@sipforum.org, sip 
References: <381682468.963947146038.JavaMail.root@web301-mc.mail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: [SIPFORUM] Some simple questions
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Technical questions on sip actually belong on the sip mailing list,
sip@lists.bell-labs.com

anyway, to answer your questions:


Xin Huang wrote:
> 
> I'm new to SIP and have some simple questions. (for page/section please refer to http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-2543bis-00.pdf)
> 
> 1. Is it legal that a UA registers on multiple registrars?

Yes.

> 
> 2. Is header "Max-Forwards" hop-to-hop or end-to-end? On page 35 (Table 4, section 6) it's marked as end-to-end. But on page 50 (section 6.28): every proxy or gateway ... MUST check and update its value ...

Its hop by hop. Thanks for catching this.


> 
> 3. Why should redirect servers support BYE? (on page 27, section 4.2.4)

Proxy and redirect servers are method independent. 

> 
> 4. Why the following headers are not listed in table 3 (page 23, section 3)?
>     Call-Info (defined in section 6.14)
>     Mime-Version (defined in section 6.29)
>     Alert-Info ( defined in section 6.10)

Oversight. THese headers have recently been discussed (in fact, there is
not yet consensus that Alert-Info and Call-Info will stay).


> And, Are "Accept-Encoding" & "Accept-Language" request headers, or general headers? (in table 3 they are general headers, in section 6.8/6.9 they are request headers).

General, I think.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Wed Jul 19 01:01:46 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26262
	for ; Wed, 19 Jul 2000 01:01:46 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A142A44389; Wed, 19 Jul 2000 01:01:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 625094433B
	for ; Wed, 19 Jul 2000 01:01:07 -0400 (EDT)
Received: from dynamicsoft.com (1Cust119.tnt7.bos2.da.uu.net [63.27.144.119])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14788;
	Wed, 19 Jul 2000 01:02:38 -0400 (EDT)
Message-ID: <397536EB.FE802074@dynamicsoft.com>
Date: Wed, 19 Jul 2000 01:04:43 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Contact in final INVITE response.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Fairlie-Cuninghame, Robert" wrote:
> 
> >
> > Let me summarize what you are trying to say here:
> >
> > 1. a server sends a 4xx response
> > 2. the UAC or proxy now needs to send an ACK
> > 3. the 4xx response was sent with a source port the server is not
> > listening on
> > 4. the ACK will not be received by the server
> >
> > I don't see why 4. follows, if that is what you are claiming. The ACK
> > should be sent to the same address and port you sent the INVITE to.
> > Obviously the server is listening there or it wouldn't have gotten the
> > INVITE in the first place. So, the ACK will be received by the server.
> >
> Thanks for the reply.
> 
> Sure, this is not a problem in the normal call flows (when you have that
> information - ie, when you have cached state for the transaction) but there
> is no way to respond to an error response you receive when you have no
> cached transaction information.
> Possible causes:
> - Client crashes
> - Client error which causes call state to be flushed (prehaps during to
> handling of reinvite or CANCEL).
> - Client does not cache original requests (for very long) after first ACK to
> final response has been sent. [This is probably the most likely reason in
> the field.]
> 
> Admittedly, most of these cases result from implementation shortcuts (or
> errors) but regardless of the cause, wouldn't it be more tidy from a
> protocol point of view (in my mind) to be able to ACK to an error response
> even when you don't have cached state for it. I think this should at the
> very least to be "A sip URL MAY be added to Contact header of 4xx+ responses
> (except for the pesky 485) to which the ACK should be sent"  - if not a
> SHOULD or MUST.

Well, this wouldn't work for 3xx responses.

What you really want is a way to place state into a request, and get it
back in a response. There is already a way to do this - everyone's
favorite parameter - the Via branch ID. You could stick the request URI
+ Ip address/port in there when you forward the request. You could also
use a new via parameter instead.

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 19 03:58:20 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27935
	for ; Wed, 19 Jul 2000 03:58:20 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E19C74434D; Wed, 19 Jul 2000 03:57:19 -0400 (EDT)
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 F1F1644336
	for ; Wed, 19 Jul 2000 03:57:15 -0400 (EDT)
Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e6J7tqv06595;
	Wed, 19 Jul 2000 09:55:53 +0200 (MET DST)
Received: from alcatel.be (bt00rd [138.203.66.122])
	by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id JAA19715;
	Wed, 19 Jul 2000 09:55:28 +0200 (MET DST)
Message-ID: <39755D46.6272642C@alcatel.be>
Date: Wed, 19 Jul 2000 09:48:22 +0200
From: Bart Van Doorselaer 
Organization: Alcatel
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "xcast@public.alcatel.com" ,
        sip , confctrl 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] FYI: ID on sip-xcast
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

The official announcement has not yet come through (or at least I did
not
see it yet), but following draft is already available:

http://www.ietf.org/internet-drafts/draft-van-doorselaer-sip-xcast-00.txt

"SIP for the establishment of xcast-based multiparty conferences",
Dirk Ooms, Bart Van Doorselaer, 07/18/2000. (41589 bytes)

Explicit Multicast (xcast) is a multicast scheme that uses an explicit
list
of destinations instead of one logical multicast address. Explicit
Multicast
complements the existing multicast schemes in that it can efficiently
support
very large numbers of distinct (small) multicast groups and thus can
play an
important role in making multicast practical for applications such as
multiparty IP telephony, various conferencing & collaborative
applications,
multiparty networked games, etc... This document explains how multiparty
IP
telephony conferences making use of xcast can be established by SIP
carrying
SDP. Some open issues will be identified and discussed. Possible
extensions
to SIP and SDP to streamline the use of xcast will be suggested as well.


Cheers,


Bart

-- 
                                              ____________________
Bart Van Doorselaer                           \                  /
_______________________________________________\                /____
                                                \              /
Research Engineer                                \  ALCATEL   /
DN2                                          Network Strategy Group
Tel   : +32 3 240 86 41                      Francis Wellesplein  1
Fax   : +32 3 240 99 32                     B-2018 Antwerpen Belgium
_____________________________________________________\    /__________
mailto:Bart.Van_Doorselaer@alcatel.be                 \  /
                                                       \/


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


From sip-admin@lists.bell-labs.com  Wed Jul 19 04:29:01 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08692
	for ; Wed, 19 Jul 2000 04:29:00 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E504D4433D; Wed, 19 Jul 2000 04:28:56 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 6A21E44336
	for ; Wed, 19 Jul 2000 04:28:45 -0400 (EDT)
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA21560; Wed, 19 Jul 2000 09:26:17 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Rohan Mahy 
Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
Date: Wed, 19 Jul 2000 08:54:05 +0100
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
Cc: sip@lists.bell-labs.com
References: <4.2.0.58.20000718082630.01c49d10@lint.cisco.com> <4.2.0.58.20000718124402.00c943e0@imop.cisco.com>
In-Reply-To: <4.2.0.58.20000718124402.00c943e0@imop.cisco.com>
MIME-Version: 1.0
Message-Id: <00071909222600.12249@gethin>
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

On Tue, 18 Jul 2000, Rohan Mahy wrote:
> Why not just translate the (;)s to (,)s or escape the (;)s?

Because rfc 2806 defines ';' as being the parameter separator and we
have to abide by its rules.  Also, ',' is a valid character in its own
right within rfc 2806 and has its own semantics.  If we changed ';' to
',' what would we change ',' to?  If we were to start trying to change
another rfc, then we should have implemented our own in the first
place. which, i suppose, is not the point of rfc's and would provide
extra un-required work for our WG.

As for escaping ';' , this was discussed eairlier in this thread.

Basically, if we were to escape `;' in our sip url, then what would we
do with the already escaped ';' in the tel url?

eg. tel:+1234;a=%3B

convert this to sip, we have

sip:+1234;a=%3B@host;user=phone

however, if we escape the % then we have

sip:+1234%3ba=%3Bhost;user=phone

how do we un-parse this?

for further dicussion and conclusion on this problem, please consult
the earlier part of this thread in the Sip Mailing List Archive

> 
> thanks,
> -rohan
-- 
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 Jul 19 05:40:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03030
	for ; Wed, 19 Jul 2000 05:40:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 855544433B; Wed, 19 Jul 2000 05:40:26 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 30C2544336
	for ; Wed, 19 Jul 2000 05:40:21 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA08028; Wed, 19 Jul 2000 10:38:12 +0100 (BST)
From: "Jo Hornsby" 
To: 
Cc: 
Subject: RE: [SIP] Questions on new loop detection mentioned in RFC2543 bis
Date: Wed, 19 Jul 2000 10:38:11 +0100
Message-ID: <000301bff165$0e03bc60$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <88256920.00686B76.00@hqoutbound.ops.3com.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> > The scenario is as follows
> >
> >
> > A---------------P1------------P2----/
> > ------P3----------P2---------P4----------B.
> >
> >
> > I assume that P2 would treat them as two different calls.
> >
> > 1)  P1-----P2------P3
> >
> > 2) P3-----P2------P4
>
> > Q3)         Can a call leg still be identified with CallID, From
> > and To headers or we need one extra identifier ( probably a hash
> > similar to one in Via) ?
> 
> Well, I guess if you need to keep tabs on both parts of the spiral,
> you could use the Request-URI.
>
> >>>> How does it route the BYE from the called party. What should 
>      a Request URI from B contain?

According to the spec, the Request-URI from B should contain
the contact address of A.  The Request-URI will contain the
contact address of A at every point along the path, in fact,
which is why we result in an illegal loop.

> I think the easiest solution is probably to just note that the
> request has spiralled, and update state for the multiple interested
> "parties" as necessary.  Is there any need for a proxy to add
> itself more than once in a Record-Route?  There can still only be
> one call leg, after all.
>
> >>>> We cannot assume that because to add to it P3 could have
>      forked the request. So while P2 sent out one
> >>>> to P3, P3 forked it and now P2 is in the path a forked
>      request. Hence we cannot assume one call leg.

I was being naiieve, but it's still not a problem.  Consider
the following two scenarios:

[1]         
                            +--------- P4
                            |           |
                            |           |
                            |           |
                            |           |
                            |           |
    A -------- P1 -------- P2 -------- P3
                            |
                            |
                            |
                            |
                            |
                            B

[2]
                            +--------- P4
                            |           |
                            |           |
                            |           |
                            |           |
                            |           |
    A -------- P1 -------- P2 -------- P3 -------- C
                            |
                            |
                            |
                            |
                            |
                            B

In case [1], the request has spiralled through P2, and the
initial INVITE results in one call leg, A<->B.

In case [2], the request has spiralled through P2, and the
initial INVITE results in two call legs, A<->B and A<->C.

In both cases, P2 can easily detect that the result has
spiralled, by looking for a match on the From, To, Call-ID, CSeq,
and ignoring the Request-URI.  Therefore, it only adds itself
to the Record-Route list the first time it sees the request
(from P1).

If the request has forked at any point, then P2 will just have
multiple To "tags" to keep track of.

Finally, if P2 needs to know that it saw the request spiral
at some point, and needs both Request-URIs, all it needs to
do is to associate some extra state with it's state on the
call-leg(s).  The call-state has to apply at both points by
implication.

> >>>>> The bottom line is CallID, From and To alone are not
>       sufficient to identify a call leg once we
> >>>>> allow this new loop detection

Call-leg is defined in terms of endpoints -- proxies just
may happen to sit along the path.  Therefore, it doesn't
matter if the Request-URI has been changed X times, and
spiralled Y times -- the notion of call-state is going to be
the same wherever.

HTH,


 - Jo.



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


From sip-admin@lists.bell-labs.com  Wed Jul 19 06:36:17 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21932
	for ; Wed, 19 Jul 2000 06:36:17 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CCF5B44391; Wed, 19 Jul 2000 06:35:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 5533E44336
	for ; Wed, 19 Jul 2000 06:35:49 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21654;
	Wed, 19 Jul 2000 06:35:48 -0400 (EDT)
Message-Id: <200007191035.GAA21654@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Date: Wed, 19 Jul 2000 06:35:48 -0400
Subject: [SIP] I-D ACTION:draft-ietf-sip-callerprefs-02.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: SIP Caller Preferences and Callee Capabilities
	Author(s)	: H. Schulzrinne, J. Rosenberg
	Filename	: draft-ietf-sip-callerprefs-02.txt
	Pages		: 26
	Date		: 18-Jul-00
	
This document describes a set of extensions to SIP which allow a
caller to express preferences about request handling in servers.
These preferences include the ability to select which URIs a call
gets proxied or redirected to, and to specify certain request
handling directives in proxies and redirect servers. It does so by
defining three new request headers, Accept-Contact, Reject-Contact
and Request-Disposition, which specify the callers preferences. The
extension also defines new parameters for the Contact header. These
extra parameters are present in the Contact header in REGISTER
requests, and are used to associated attributes with particular
addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-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-callerprefs-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-callerprefs-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:	<20000718140723.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-callerprefs-02.txt

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

Content-Type: text/plain
Content-ID:	<20000718140723.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 Jul 19 06:37:17 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22443
	for ; Wed, 19 Jul 2000 06:37:17 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 105A3443A9; Wed, 19 Jul 2000 06:36:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id B81E1443A0
	for ; Wed, 19 Jul 2000 06:35:54 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21704;
	Wed, 19 Jul 2000 06:35:53 -0400 (EDT)
Message-Id: <200007191035.GAA21704@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Date: Wed, 19 Jul 2000 06:35:53 -0400
Subject: [SIP] I-D ACTION:draft-ietf-sip-session-timer-02.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

--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-02.txt
	Pages		: 19
	Date		: 18-Jul-00
	
This document proposes an extension to the Session Initiation
Protocol (SIP). This extension allows for a periodic refresh of SIP
sessions through a re-INVITE. The refresh allows both user agents and
call stateful proxies to determine in the SIP session is still
active. The extension defines a new general header, Session-Expires,
which conveys the lifetime of the session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-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-session-timer-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-session-timer-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:	<20000718140733.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-session-timer-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-session-timer-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000718140733.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 Jul 19 10:14:58 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18060
	for ; Wed, 19 Jul 2000 10:14:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0605E443A9; Wed, 19 Jul 2000 10:14:09 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id E685944341
	for ; Wed, 19 Jul 2000 10:14:02 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 19 10:13:30 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id D3C3244360; Wed, 19 Jul 2000 09:47:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2])
	by lists.bell-labs.com (Postfix) with SMTP
	id 4323444347; Wed, 19 Jul 2000 09:47:11 -0400 (EDT)
Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA07778; Wed, 19 Jul 2000 09:47:10 -0400
Message-ID: <3975B15A.A9EACF28@lucent.com>
Date: Wed, 19 Jul 2000 09:47:06 -0400
From: Hui-Lan Lu 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4  (WinNT; U)
X-Accept-Language: zh-TW,zh-CN
MIME-Version: 1.0
To: ietf@ietf.org, sip@lists.bell-labs.com, pint@lists.bell-labs.com,
        spirits@lists.bell-labs.com, iptel@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] The New Mailing list for SIP/IN Interworking
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


A mailing list for the upcoming BOF on SIP/IN interworking (SIN) has
been set up to begin the relevant discussion. To join the list
(ietf-sin@lists.bell-labs.com), please follow the instructions at
http://lists.bell-labs.com/mailman/listinfo/ietf-sin.

Hui-Lan Lu
Lucent Technologies


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


From sip-admin@lists.bell-labs.com  Wed Jul 19 10:48:14 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01038
	for ; Wed, 19 Jul 2000 10:48:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 557884433F; Wed, 19 Jul 2000 10:47:58 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5])
	by lists.bell-labs.com (Postfix) with ESMTP id 35DB044336
	for ; Wed, 19 Jul 2000 10:47:55 -0400 (EDT)
Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1)
	id 13Ev8O-0006Qv-00; Wed, 19 Jul 2000 15:47:40 +0100
Date: Wed, 19 Jul 2000 15:47:36 +0100 (BST)
From: Lloyd Wood 
X-Sender: eep1lw@petra.ee.surrey.ac.uk
Reply-To: L.Wood@eim.surrey.ac.uk
To: Hui-Lan Lu 
Cc: ietf@ietf.org, sip@lists.bell-labs.com
In-Reply-To: <3975B15A.A9EACF28@lucent.com>
Message-ID: 
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [SIP] Re: The New Mailing list for SIP/IN Interworking
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

On Wed, 19 Jul 2000, Hui-Lan Lu wrote:

> A mailing list for the upcoming BOF on SIP/IN interworking (SIN) has
> been set up to begin the relevant discussion. To join the list
> (ietf-sin@lists.bell-labs.com), please follow the instructions at
> http://lists.bell-labs.com/mailman/listinfo/ietf-sin.

"The current archive is only available to the list members."?

Not very spirit-of-IETF.

L.

PGP



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


From sip-admin@lists.bell-labs.com  Wed Jul 19 11: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 ESMTP id LAA21005
	for ; Wed, 19 Jul 2000 11:37:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AB2F644389; Wed, 19 Jul 2000 11:36:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from june.idc1.level3.com (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 3A91544336
	for ; Wed, 19 Jul 2000 11:36:35 -0400 (EDT)
Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140])
	by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id PAA19231
	for ; Wed, 19 Jul 2000 15:36:34 GMT
From: Aparna.Vemuri@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id JAA23973
	for ; Wed, 19 Jul 2000 09:36:34 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 19 Jul 2000 09:38:16 -0600
Message-ID: 
To: sip@lists.bell-labs.com
Date: Wed, 19 Jul 2000 09:36:32 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] SIP-T Context and Architectures Internet Draft
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hello.
A new Internet Draft describing the context and architectures in which SIP-T
may be used is now available at:
http://www.ietf.org/internet-drafts/draft-vemuri-sip-t-context-00.txt
Comments are welcome.


Aparna V.
Level (3) Communications.






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


From sip-admin@lists.bell-labs.com  Wed Jul 19 12:16:35 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08142
	for ; Wed, 19 Jul 2000 12:16:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AF0AF44396; Wed, 19 Jul 2000 12:16:06 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id AC01A4433D
	for ; Wed, 19 Jul 2000 12:16:02 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 19 12:15:14 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id E9D9D4435D; Wed, 19 Jul 2000 12:02:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2])
	by lists.bell-labs.com (Postfix) with SMTP id B9F0444347
	for ; Wed, 19 Jul 2000 12:02:04 -0400 (EDT)
Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA20761; Wed, 19 Jul 2000 12:02:03 -0400
Message-ID: <3975D0FA.3C736E5A@lucent.com>
Date: Wed, 19 Jul 2000 12:02:02 -0400
From: Hui-Lan Lu 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4  (WinNT; U)
X-Accept-Language: zh-TW,zh-CN
MIME-Version: 1.0
To: L.Wood@eim.surrey.ac.uk
Cc: ietf@ietf.org, sip@lists.bell-labs.com
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: The New Mailing list for SIP/IN Interworking
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit




Lloyd Wood wrote:
> 
> On Wed, 19 Jul 2000, Hui-Lan Lu wrote:
> 
> > A mailing list for the upcoming BOF on SIP/IN interworking (SIN) has
> > been set up to begin the relevant discussion. To join the list
> > (ietf-sin@lists.bell-labs.com), please follow the instructions at
> > http://lists.bell-labs.com/mailman/listinfo/ietf-sin.
> 
> "The current archive is only available to the list members."?
> 
> Not very spirit-of-IETF.

The archive is now set to be public. Thanks for spotting the problem.

Hui-Lan Lu
Lucent Technologies


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


From sip-admin@lists.bell-labs.com  Wed Jul 19 12:17:52 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08604
	for ; Wed, 19 Jul 2000 12:17:51 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 425F8443BF; Wed, 19 Jul 2000 12:16:54 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 9147A443B6
	for ; Wed, 19 Jul 2000 12:16:46 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id RAA26966; Wed, 19 Jul 2000 17:14:56 +0100 (BST)
From: "Jo Hornsby" 
To: 
Date: Wed, 19 Jul 2000 17:14:56 +0100
Message-ID: <000701bff19c$7aac07f0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] Record-Route and ports (Was: Questions on new loop detection mentioned in RFC2543 bis)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

The cogs in my mind have been slowly turning, and I am now
worried. &:)

Section 6.35.2 (Construction of a Route Header) of the most
recent draft, states the following:
   "If a UA find a Record-Route header in a request, it copies the
   Record-Route maddr parameters only, maintaining their ordering, to
   the Route header field of future requests. 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 originating name-addr value."

This means that there is no way for a proxy to indicate what
port to send to.  In fact, I think it's worse than that, since
I think that correct client behaviour specifies that a client
should send to the address in the Request-URI.  Now, the maddr
will override the IP, but if the originating UA Contact address
contained a port that wasn't 5060, couldn't subsequent requests
from Callee to Caller get completely lost?

(I also note that 6.47.3 says nothing about sending to the port
in the received parameter -- surely this is incorrect, given
the "special" behaviour of User Agent and Redirect Servers in
6.47.4?)

It would be unwise to change the behaviour in 6.35.2 so that
the name-addr included the appropriate port, I guess, since
then the Contact address could be broken; however, I'm not sure
that doing something like adding a `proxy-port' parameter is
any better (it should be backwards compatible, but proxies
are still going to have to be receptive on 5060 to work with
older clients).

Thoughts?

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 Jul 19 17:50:36 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26381
	for ; Wed, 19 Jul 2000 17:50:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E61C64438F; Wed, 19 Jul 2000 17:50:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 137F34433B
	for ; Wed, 19 Jul 2000 17:50:12 -0400 (EDT)
Received: from dynamicsoft.com ([63.89.18.83])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA19940
	for ; Wed, 19 Jul 2000 17:51:42 -0400 (EDT)
Message-ID: <3976236E.5CDE2265@dynamicsoft.com>
Date: Wed, 19 Jul 2000 17:53:50 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-session-timer-02.txt
References: <200007191035.GAA21704@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Folks,

Please take a look at this draft. There were a few big changes based on
list discussion. We fixed it up so that only one side needs to support
session timer.

-Jonathan R.

Internet-Drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol Working Group of the IETF.
> 
>         Title           : SIP Session Timer
>         Author(s)       : S. Donovan, J. Rosenberg
>         Filename        : draft-ietf-sip-session-timer-02.txt
>         Pages           : 19
>         Date            : 18-Jul-00
> 
> This document proposes an extension to the Session Initiation
> Protocol (SIP). This extension allows for a periodic refresh of SIP
> sessions through a re-INVITE. The refresh allows both user agents and
> call stateful proxies to determine in the SIP session is still
> active. The extension defines a new general header, Session-Expires,
> which conveys the lifetime of the session.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-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-session-timer-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-session-timer-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.
> 
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <20000718140733.I-D@ietf.org>

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 19 17:56:40 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28451
	for ; Wed, 19 Jul 2000 17:56:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BB60C443BF; Wed, 19 Jul 2000 17:56:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CCF36443B2
	for ; Wed, 19 Jul 2000 17:56:11 -0400 (EDT)
Received: from dynamicsoft.com ([63.89.18.83])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA19976;
	Wed, 19 Jul 2000 17:57:15 -0400 (EDT)
Message-ID: <397624B8.152440D8@dynamicsoft.com>
Date: Wed, 19 Jul 2000 17:59:20 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema 
Cc: "'William Lee'" ,
        "'Philip Levis'" , sip@lists.bell-labs.com
Subject: Re: [SIP] Multiple sessions in SDP payload
References: <2E3FA0558747934A8F753CC533A3F6DF043C31B2@red-msg-24.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

There is no way to do this kind of thing with SDP. But, there are lots
of other things you also can't do. I believe SDP covers some 95% of the
most common application cases. So, there are a few options for the
remaining 5%. Either hack the daylights out of SDP, else use SDPng,
which mmusic is looking at. I guess its a matter of preference about
which you do.

-Jonathan R.

Christian Huitema wrote:
> 
> Jonathan,
> 
> Suppose a station wants to encode its desire to support both RTP over IPv6
> and RTP over IPv4. Due to various constraints, it cannot use the same
> listening UDP port for IPv4 and IPv6. In the current definition of SDP, the
> port number is encoded as the token immediately following the media type in
> the "m=" line, and the address type is encoded on a "c=" line. How can I
> possibly encode the SDP without having two media lines?
> 
> Christian Huitema
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Tuesday, July 18, 2000 7:17 AM
> > To: Christian Huitema
> > Cc: 'William Lee'; 'Philip Levis'; sip@lists.bell-labs.com
> > Subject: Re: [SIP] Multiple sessions in SDP payload
> >
> >
> >
> > Christian Huitema wrote:
> > > The problem is, there is a fundamental contradiction
> > between two requirements. If I include 3 "m=audio" lines, do
> > they describe
> > > 3 ways to pass audio, such as IPv4, IPv6 and POTS, or do I
> > describe 3 audio channels that should be deployed in parallel? My
> > > take so far would be to use multiple instance of the same
> > media within a single SDP payload to describe alternative encodings,
> > > and to use multiple SDP payloads, using MIME multipart, to
> > encode several parallel sessions.
> >
> > I think three lines of the same type means the same thing it does in
> > SAPs usage - parallel media streams, not alternatives. This,
> > in fact, is
> > necessary as per the other thread on sending DTMF using
> > rfc2833 to third
> > party application servers.
> >
> >
> > As for multiple sessions per SDP, I don't know what the value of this
> > would be. rfc2543 is silent on this, and I would suggest it be
> > disallowed within SIP.
> >
> > -Jonathan R.
> >
> > >        -----Original Message-----
> > >        From: William Lee [mailto:williaml@nortelnetworks.com]
> > >        Sent: Monday, July 17, 2000 10:15 PM
> > >        To: 'Philip Levis'
> > >        Cc: sip@lists.bell-labs.com
> > >        Subject: RE: [SIP] Multiple sessions in SDP payload
> > >
> > >        Yes, according to the spec, multiple SDP sessions
> > may be specified.
> > >        At the 2nd SIP bake-off, we tested a trial
> > implementation of our
> > >        SDP parser/statemachine that sent and received
> > multiple SDP sessions.
> > >        No one supported this, and as far as I know no one
> > else does today.
> >
> >
> >
> > --
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> > http://www.dynamicsoft.com
> >

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 19 19:39:57 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04299
	for ; Wed, 19 Jul 2000 19:39:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 67AB44434D; Wed, 19 Jul 2000 19:39:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from seattle.3com.com (seattle.3com.com [129.213.128.97])
	by lists.bell-labs.com (Postfix) with ESMTP id 9B6444433B
	for ; Wed, 19 Jul 2000 19:39:19 -0400 (EDT)
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12])
	by seattle.3com.com (8.8.8/8.8.8) with ESMTP id QAA23758
	for ; Wed, 19 Jul 2000 16:39:18 -0700 (PDT)
From: Deepak_Pant@3com.com
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by new-york.3com.com (8.8.8/8.8.8) with SMTP id QAA26899
	for ; Wed, 19 Jul 2000 16:38:51 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256921.0081D2C5 ; Wed, 19 Jul 2000 16:38:01 -0700
X-Lotus-FromDomain: 3COM
To: sip@lists.bell-labs.com
Message-ID: <88256921.00818F7F.00@hqoutbound.ops.3com.com>
Date: Wed, 19 Jul 2000 18:37:11 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] hiding via field and loop detection
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com



The current definition for via field encryption says that
a client can request a server to encrypt a via header.

However since it is the next server that is going to encrypt
the via header, in case of a loop, the current server cannot
check if it is in the via list.


A---------P1---------P2
                |                 |
                |                 |
                |                 |
               P3---------P4


Say P1 intoduces Hide: route header in the request sent to P2 and
the request loops back to P1. Since the via is encrypted by P2
P1 won't be able to decrypt it and we are unable to detect a loop.

P2 can detect the loop on P1's behalf by seeing P1 twice on the via
list. However the loop detection is meant for own and not for some
other proxy.
-Deepak





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


From sip-admin@lists.bell-labs.com  Wed Jul 19 20:04:11 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12612
	for ; Wed, 19 Jul 2000 20:04:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EC5154438F; Wed, 19 Jul 2000 20:04:05 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id C6C134433F
	for ; Wed, 19 Jul 2000 20:04:02 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 19 20:03:35 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 0A8DC4435D; Wed, 19 Jul 2000 19:50:26 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by lists.bell-labs.com (Postfix) with ESMTP id D311B44347
	for ; Wed, 19 Jul 2000 19:50:25 -0400 (EDT)
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA17768;
	Wed, 19 Jul 2000 19:50:01 -0400 (EDT)
Message-ID: <39763EA4.C13D3D82@cs.columbia.edu>
Date: Wed, 19 Jul 2000 19:49:56 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: discussion@sipforum.org, sip 
Subject: Re: [SIP] Re: [SIPFORUM] Some simple questions
References: <381682468.963947146038.JavaMail.root@web301-mc.mail.com> <39753557.D75BBFCF@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 


> >
> > 2. Is header "Max-Forwards" hop-to-hop or end-to-end? On page 35 (Table 4, section 6) it's marked as end-to-end. But on page 50 (section 6.28): every proxy or gateway ... MUST check and update its value ...
> 
> Its hop by hop. Thanks for catching this.

This is actually a bit more complicated in that the SIP hop-by-hop
definition is drifting a bit from the HTTP hop-by-hop definition. In
HTTP, Max-Forwards is considered an end-to-end header for some reason.

> 
> >
> > 3. Why should redirect servers support BYE? (on page 27, section 4.2.4)
> 
> Proxy and redirect servers are method independent.

Modified text to 

  The methods are defined below.  Proxy and redirect servers treat
all     
  methods other than {\INVITE} and {\CANCEL} in the same way,
by           
  forwarding them accordingly. Thus, no method-specific support
is         
  required in these servers for methods other than {\INVITE} and  
{\CANCEL}.


> 
> >
> > 4. Why the following headers are not listed in table 3 (page 23, section 3)?
> >     Call-Info (defined in section 6.14)
> >     Mime-Version (defined in section 6.29)
> >     Alert-Info ( defined in section 6.10)
> 
> Oversight. THese headers have recently been discussed (in fact, there is
> not yet consensus that Alert-Info and Call-Info will stay).

Indeed. I'm hoping that we'll get this settled in Pittsburgh. Inclusion
in the spec draft is meant to encourage those that dislike their
existence or definition to speak up, in particular since not everyone
that reads the spec subscribes to the mailing list.

> 
> > And, Are "Accept-Encoding" & "Accept-Language" request headers, or general headers? (in table 3 they are general headers, in section 6.8/6.9 they are request headers).
> 
> General, I think.

HTTP/1.1 defines them as request headers, but since SIP defines them to
be also applicable to 415, they'd be general headers.

Thanks for catching these discrepancies.


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 01:16:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06403
	for ; Thu, 20 Jul 2000 01:16:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 41DED44388; Thu, 20 Jul 2000 01:16:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 0E3794433F
	for ; Thu, 20 Jul 2000 01:16:05 -0400 (EDT)
Received: from dynamicsoft.com (1Cust25.tnt1.freehold.nj.da.uu.net [63.17.113.25])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA21340;
	Thu, 20 Jul 2000 01:17:35 -0400 (EDT)
Message-ID: <39768BF3.B7D24569@dynamicsoft.com>
Date: Thu, 20 Jul 2000 01:19:47 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Deepak_Pant@3com.com
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] hiding via field and loop detection
References: <88256921.00818F7F.00@hqoutbound.ops.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

THis is addressed in the spec. From Section 6.22:

> A server that is capable of hiding Via headers MUST attempt to
>    decrypt all Via headers marked as "hidden" to perform loop detection.
>    Servers that are not capable of hiding can ignore hidden Via fields
>    in their loop detection algorithm.
> 
> 
>         If hidden headers were not marked, a proxy would have to
>         decrypt all headers to detect loops, just in case one was
>         encrypted, as the Hide: Hop option may have been removed
>         along the way.
> 
>    A host MUST NOT add such a "Hide: hop" header field unless it can
>    guarantee it will only send a request for this destination to the
>    same next hop. The reason for this is that it is possible that the
>    request will loop back through this same hop from a downstream proxy.
>    The loop will be detected by the next hop if the choice of next hop
>    is fixed, but could loop an arbitrary number of times otherwise.

So, the loop is detected by the next hop after the loop. 

-Jonathan R.

Deepak_Pant@3com.com wrote:
> 
> The current definition for via field encryption says that
> a client can request a server to encrypt a via header.
> 
> However since it is the next server that is going to encrypt
> the via header, in case of a loop, the current server cannot
> check if it is in the via list.
> 
> A---------P1---------P2
>                 |                 |
>                 |                 |
>                 |                 |
>                P3---------P4
> 
> Say P1 intoduces Hide: route header in the request sent to P2 and
> the request loops back to P1. Since the via is encrypted by P2
> P1 won't be able to decrypt it and we are unable to detect a loop.
> 
> P2 can detect the loop on P1's behalf by seeing P1 twice on the via
> list. However the loop detection is meant for own and not for some
> other proxy.
> -Deepak
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 01:22: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 ESMTP id BAA10490
	for ; Thu, 20 Jul 2000 01:22:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1DAEE443B6; Thu, 20 Jul 2000 01:22:44 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id DA1A1443B1
	for ; Thu, 20 Jul 2000 01:22:41 -0400 (EDT)
Received: from dynamicsoft.com (1Cust25.tnt1.freehold.nj.da.uu.net [63.17.113.25])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA21353
	for ; Thu, 20 Jul 2000 01:24:12 -0400 (EDT)
Message-ID: <39768D80.490F18A2@dynamicsoft.com>
Date: Thu, 20 Jul 2000 01:26:24 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] collecting items for discussion
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Folks,

The primary purpose of the IETF meetings is to enable high-bandwidth
communications amongst participants to resolve open issues in documents
and open issues on the list. As such, I plan on spending a lot of time
during the meetings trying to close issues raised on the mailing list
that went unresolved. At the last meeting, I determined the set of
unresolved issues by going back over the archives and re-reading
everything. Well, this list has gotten way too active for that, so I am
resorting to a more distributed approach.

If you raised an issue on the list which you do not believe was
resolved, please send me a note indicating what the issue was, and if
possible, a pointer to the beginning of the thread in the archives. I'll
make a list and figure out which topics we need to discuss at the
meeting. Also, to make my own email management easier, please use the
subject line "SIP LIST OPEN ISSUE" so I can make sure to put them all in
the same place.

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: (732) 741-7244
http://www.dynamicsoft.com


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 05:23:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06101
	for ; Thu, 20 Jul 2000 05:23:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3E4E04438F; Thu, 20 Jul 2000 05:23:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from roma.axis.se (roma.axis.se [193.13.178.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 59CFE4433B
	for ; Thu, 20 Jul 2000 05:23:32 -0400 (EDT)
Received: from saur.axis.se (IDENT:root@saur.axis.se [171.16.116.30])
	by roma.axis.se (8.9.3/8.9.3) with ESMTP id LAA22896
	for ; Thu, 20 Jul 2000 11:23:03 +0200 (MEST)
Received: from saur (IDENT:pkj@localhost [127.0.0.1])
	by saur.axis.se (8.9.3/8.8.8) with ESMTP id LAA08961
	for ; Thu, 20 Jul 2000 11:23:02 +0200
Message-Id: <200007200923.LAA08961@saur.axis.se>
X-Mailer: exmh version 2.0.2
To: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Thu, 20 Jul 2000 11:23:02 +0200
From: Peter Kjellerstedt 
Subject: [SIP] Inconsistencies and questions regarding latest 2543bis draft
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

Hello,

the following are a number of inconsistencies and questions
that I have found while studying the latest 2543bis draft 
(July 13). I hope they can be fixed/answered.

1) Table 2 is not consistent with the text:

   In the text about URL parameters it is specified that
   transport, maddr and ttl MUST NOT be present in From and To
   headers and in the Request-URI, but still they are listed
   in table 2 as optitional for the Request-URI.

2) In 6.10 (Alert-Info):

   The syntax looks very odd with upside-down ! and ? around
   the URI... I suppose they should really be "<" and ">"
   (as indicated by the example).

3) In 6.14 (Call-Info):

   There should be quotation marks (") around the purpose
   parameter name in the syntax definition.

   Must the purpose parameter really be the first one as stated by
   the grammar, or can it be anywhere among the parameters (as is
   the case with just about every other parameter list specified
   in the draft)?

4) In 6.15 (Contact) and 11.1 (Behaviour of SIP User Agents):

   It is stated in 6.15 that a Contact header MUST be present
   in an INVITE. In 11.1 it is said that you MAY add a Contact
   to an INVITE...

5) In 6.16 (Content-Disposition):

   The extension-token rule is not defined anywhere. I suppose it
   should just be a token, but anyway...

6) In 6.35.4 (Record-Route Syntax) and 6.39 (Route):

   Should the syntax for Record-Route (similar for Route) not be

      record-route = "Record-Route" ":" 1# (name-addr [rr-extension])

   instead of

      record-route = "Record-Route" ":" 1# name-addr [rr-extension]

   or is the extension really meant for all the recorded routes
   appearing on the same line, and not each one individually?
   This is inconsistent with all other similar headers.

   Why is it [rr-extension] and not *(';' rr-extension)  ?
   Is there no possibility of wanting more than one parameter
   for Record-Route and Route?

7) In 6.35.4 (Record-Route Syntax) and 6.47.5 (Via Syntax):
   
   The syntax for rr-extension and via-extension could be redefined
   to use the generic-param rule to keep them consistent with all
   the other parameters that were changed in this way.

//Peter


------------------------------------------------------------
Peter Kjellerstedt       E-Mail: Peter.Kjellerstedt@axis.com
Axis Communications AB   Phone:  +46 46 272 18 69
Scheelevagen 34          Fax:    +46 46 13 61 30
SE-223 63 LUND           URL:    http://www.axis.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 Jul 20 06: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 ESMTP id GAA27398
	for ; Thu, 20 Jul 2000 06:14:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3CC4F443B1; Thu, 20 Jul 2000 06:13:47 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 42DF74433B
	for ; Thu, 20 Jul 2000 06:13:43 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id LAA18647; Thu, 20 Jul 2000 11:11:22 +0100 (BST)
From: "Jo Hornsby" 
To: "Jonathan Rosenberg" , 
Cc: 
Subject: RE: [SIP] hiding via field and loop detection
Date: Thu, 20 Jul 2000 11:11:21 +0100
Message-ID: <000e01bff232$da24bab0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <39768BF3.B7D24569@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> So, the loop is detected by the next hop after the loop. 
[...]
> > A---------P1---------P2
> >            |          |
> >            |          |
> >            |          |
> >           P3---------P4
[P1 has requested Hide: hop, so cannot detect the loop.]

In this case, how should P2 respond?  In the case of an INVITE,
I think there's a problem, since ACK-based reliability is going
to screw things up.

P2 now has "two" requests: P1P2 and P1P2L (looped).  If P2
responds with a 482, P1 could potentially figure out which
request was being responded to by looking at the Vias; however,
if it now ACKs that response, since the response is generated
locally, there will only be one Via, so P2 cannot determine
whether this ACK is for the INVITE P1P2 or P1P2L.  (This is
similar to the problem with aggressively detecting request-
merging situations at arbitrary points downstream.)

Would the best thing be for P2 just not to respond?  P1 will
then eventually time-out, and return 408, or something.  This
should end up doing (roughly) the Right Thing; there's just
potential for information lossage.

Alternatively, P2 could note the loop, CANCEL the branch spawned
by the P1P2 (first) request and return 482 (for P1P2).  The
problem with this would be if either P3 or P4 had forked, since
the INVITE could still be successful along other routes.

Finally, P2 could respond with 482 in the normal fashion, and
add some special tag to the To header.  In this case, it would
be able to distinguish the ACKs.  The only time it wouldn't be
able to do this would be if the request already had a tag in
the To header, but I guess looping is far less likely on
re-INVITEs.

I note that if P1 ever issues a CANCEL for whatever reason,
P2 has no chance.  Should policy be to go with the most routed
request?  (If the request had forked at other points, this
could be considered desirable.)

This isn't such an issue for non-INVITEs, since there is no
ACK to worry about.  The proxies do still need to examine
Vias to figure out exactly which request they're responding-to/
receiving; and there is still the same problem with CANCEL.

One last point: perhaps it would be an idea that the spec
RECOMMENDED that either proxies add a unique (a la tag) parameter
to their Vias -- "proxy", or something -- or make the branch
parameter of their Vias uniquely recognisable somehow.  Since
the parameters are not encrypted, this would allow a proxy to
recognise a looped request without having to do any sort of
decryption.

Comments?

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 Jul 20 07:58:54 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20642
	for ; Thu, 20 Jul 2000 07:58:54 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7FCE2443B7; Thu, 20 Jul 2000 07:58:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id C37994433B
	for ; Thu, 20 Jul 2000 07:58:04 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7J17Q3>; Thu, 20 Jul 2000 04:58:33 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'sip@lists.bell-labs.com'" 
Date: Thu, 20 Jul 2000 04:58:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Adding tags across reboots.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


I have two queries, the first is about the handling of received INVITE's
when you have no call state (affecting robustness after crash); the second
more serious query is about handling BYE, CANCEL, INFO requests when you
have no call state.

In Section 1.5 (point 1)  there is a whole paragraph devoted to behaviour of
clients that wish to be robust across a crash. 

Consider the following scenario: UA1 sends INVITE (with no To or From tags)
to UA2. UA2 adds a To tag in the 200Ok response and this is used in all
subsequent transactions by both UA's as per RFC.

Now UA1 crashes and reboot. UA2 sends a re-INVITE to UA1 (perhaps due to
Session Timer). This re-INVITE will have a From tag but no To tag and UA1
will treat the re-INIVTE as new call, correct? Thus, it will then add
_another_ To tag (in what was originally the From field). 

Should UA2 match this 200Ok response to the existing call ? No, you can't
change the From tag mid-call. So in this situation you can't recover from a
crash, right ? So how do you handle this ? [Distinguishing an INVITE from a
re-INVITE without call state]. I have one suggestion at the end of this
email.

Now, what about handling _non-INVITE_ requests after a crash. In Section
6.44 (To), it says that a UAS must place a tag on all final responses to all
transactions within a call leg. And Section 11 is unclear on what to do.

Let's consider the same scenario described above except when UA1 receives a
BYE from UA2 after a crash (which is probably much more likely). This
scenario extends to whenever you receive a BYE, INFO, CANCEL or similar
post-INVITE request - whenever you would want respond with a 481 Not
exist(ie no call state).

UA1 should return a 481 request when it receives the BYE/INFO/CANCEL but
once again if it was to place a To tag in the 481 response then UA2 would
not be able to match the response to the request. 

I think the spec should be clarified in Section11 as to the behaviour when
BYE/INFO/CANCEL/etc responses are received but no call state exists.
Is the correct behaviour NOT to add a To tag when issuing a 481? Can anyone
think of some way in which this will affect forking proxies - I beleive it
should be okay as these requests do not relete to call establisment.

One solution that would fix all these problems is to make a From tag
mandatory in INVITE's (even if it is just tag=0) so that a new tag will not
be added, however this is a fairly heavy burden.

Any other ideas?

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 Jul 20 11: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 ESMTP id LAA07343
	for ; Thu, 20 Jul 2000 11:21:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D4A77443C3; Thu, 20 Jul 2000 11:21:20 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 78E324433B
	for ; Thu, 20 Jul 2000 11:21:14 -0400 (EDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA25761;
	Thu, 20 Jul 2000 08:21:28 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA13968; Thu, 20 Jul 2000 08:21:18 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14711.6382.537163.305937@thomasm-u1.cisco.com>
Date: Thu, 20 Jul 2000 08:21:18 -0700 (PDT)
To: "Fox, Mike" 
Cc: Jonathan Rosenberg , sip@lists.bell-labs.com
Subject: RE: [SIP] How to stop a Lawnmower Man attack?
In-Reply-To: <613A6A6A3F09D3118F5C00508B2C24FEAD8B73@sd_exchange.nuera.com>
References: <613A6A6A3F09D3118F5C00508B2C24FEAD8B73@sd_exchange.nuera.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Fox, Mike writes:
 > Perhaps, but the point is not to reduce the service users have access to but
 > increase and improve them. Administrative domains which enable better
 > services can be considered. Users on administrative islands do not get as
 > good visibility into what is happening on the network. For example, I do not
 > want to be part of a prank I would like my service provider to recognize the
 > signature of pranks and stop them. If my UAC is behaving badly because it
 > got some virus I want it stopped. Most "users" do not want to be
 > administrators, and recognize the benefits of the administrative function.
 > Perhaps I'm wrong but it seems that many SIP endorsers have ideologically
 > eschew the concept of administrative control, but it can be useful. 
 > 
 > I would like to be clear in that I'm not trying to suggest that SIP does
 > support administrative control. Instead I would like to suggest that such
 > models are possible, and that a community effort in addressing security
 > threats could yield useful results.

   I don't see how the protocol itself can help. I can
   see pretty simple call gapping measures at proxies,
   etc, help though but those don't require any new
   protocol mechanisms. Also: a UAS can always insist
   that the initial INVITE come through a trusted 
   proxy rather than directly from the UAC. Assuming
   that proxies are more trustworthy because they at
   least have some admin behind them, you could limit
   the zombie attack as above.

   Am I missing something?

		Mike


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 12:10:11 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01949
	for ; Thu, 20 Jul 2000 12:10:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3961B443C6; Thu, 20 Jul 2000 12:09:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id E79674433B
	for ; Thu, 20 Jul 2000 12:09:42 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA00063;
	Thu, 20 Jul 2000 12:09:42 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA21861;
	Thu, 20 Jul 2000 12:09:41 -0400 (EDT)
Message-ID: <39772445.6BC31AA0@cs.columbia.edu>
Date: Thu, 20 Jul 2000 12:09:41 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Adding tags across reboots.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

One possibility is to make the From/To tags constant across reboots and
only dependent on the system identity, not its incarnation index. For
example, this could be a hash of the user id and a processor ID and MAC
address.


"Fairlie-Cuninghame, Robert" wrote:
> 
> I have two queries, the first is about the handling of received INVITE's
> when you have no call state (affecting robustness after crash); the second
> more serious query is about handling BYE, CANCEL, INFO requests when you
> have no call state.
> 
> In Section 1.5 (point 1)  there is a whole paragraph devoted to behaviour of
> clients that wish to be robust across a crash.
> 
> Consider the following scenario: UA1 sends INVITE (with no To or From tags)
> to UA2. UA2 adds a To tag in the 200Ok response and this is used in all
> subsequent transactions by both UA's as per RFC.
> 
> Now UA1 crashes and reboot. UA2 sends a re-INVITE to UA1 (perhaps due to
> Session Timer). This re-INVITE will have a From tag but no To tag and UA1
> will treat the re-INIVTE as new call, correct? Thus, it will then add
> _another_ To tag (in what was originally the From field).
> 
> Should UA2 match this 200Ok response to the existing call ? No, you can't
> change the From tag mid-call. So in this situation you can't recover from a
> crash, right ? So how do you handle this ? [Distinguishing an INVITE from a
> re-INVITE without call state]. I have one suggestion at the end of this
> email.
> 
> Now, what about handling _non-INVITE_ requests after a crash. In Section
> 6.44 (To), it says that a UAS must place a tag on all final responses to all
> transactions within a call leg. And Section 11 is unclear on what to do.
> 
> Let's consider the same scenario described above except when UA1 receives a
> BYE from UA2 after a crash (which is probably much more likely). This
> scenario extends to whenever you receive a BYE, INFO, CANCEL or similar
> post-INVITE request - whenever you would want respond with a 481 Not
> exist(ie no call state).
> 
> UA1 should return a 481 request when it receives the BYE/INFO/CANCEL but
> once again if it was to place a To tag in the 481 response then UA2 would
> not be able to match the response to the request.
> 
> I think the spec should be clarified in Section11 as to the behaviour when
> BYE/INFO/CANCEL/etc responses are received but no call state exists.
> Is the correct behaviour NOT to add a To tag when issuing a 481? Can anyone
> think of some way in which this will affect forking proxies - I beleive it
> should be okay as these requests do not relete to call establisment.
> 
> One solution that would fix all these problems is to make a From tag
> mandatory in INVITE's (even if it is just tag=0) so that a new tag will not
> be added, however this is a fairly heavy burden.
> 
> Any other ideas?
> 
> Robert.
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 12:16:57 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05362
	for ; Thu, 20 Jul 2000 12:16:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0F82C443CC; Thu, 20 Jul 2000 12:16:21 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id D9EB04437B
	for ; Thu, 20 Jul 2000 12:16:17 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7J18DY>; Thu, 20 Jul 2000 09:16:46 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Henning Schulzrinne'" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Adding tags across reboots.
Date: Thu, 20 Jul 2000 09:16:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

But in the scenario I described you would still be adding a tag to a URL
that didn't have one before (because the From URL never originally had a
tag) - thereby changing the call leg identifiers. 

Robert.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: Friday, July 21, 2000 12:10 AM
> To: Fairlie-Cuninghame, Robert
> Cc: 'sip@lists.bell-labs.com'
> Subject: Re: [SIP] Adding tags across reboots.
> 
> 
> One possibility is to make the From/To tags constant across 
> reboots and
> only dependent on the system identity, not its incarnation index. For
> example, this could be a hash of the user id and a processor 
> ID and MAC
> address.
> 
> 
> "Fairlie-Cuninghame, Robert" wrote:
> > 
> > I have two queries, the first is about the handling of 
> received INVITE's
> > when you have no call state (affecting robustness after 
> crash); the second
> > more serious query is about handling BYE, CANCEL, INFO 
> requests when you
> > have no call state.
> > 
> > In Section 1.5 (point 1)  there is a whole paragraph 
> devoted to behaviour of
> > clients that wish to be robust across a crash.
> > 
> > Consider the following scenario: UA1 sends INVITE (with no 
> To or From tags)
> > to UA2. UA2 adds a To tag in the 200Ok response and this is 
> used in all
> > subsequent transactions by both UA's as per RFC.
> > 
> > Now UA1 crashes and reboot. UA2 sends a re-INVITE to UA1 
> (perhaps due to
> > Session Timer). This re-INVITE will have a From tag but no 
> To tag and UA1
> > will treat the re-INIVTE as new call, correct? Thus, it 
> will then add
> > _another_ To tag (in what was originally the From field).
> > 
> > Should UA2 match this 200Ok response to the existing call ? 
> No, you can't
> > change the From tag mid-call. So in this situation you 
> can't recover from a
> > crash, right ? So how do you handle this ? [Distinguishing 
> an INVITE from a
> > re-INVITE without call state]. I have one suggestion at the 
> end of this
> > email.
> > 
> > Now, what about handling _non-INVITE_ requests after a 
> crash. In Section
> > 6.44 (To), it says that a UAS must place a tag on all final 
> responses to all
> > transactions within a call leg. And Section 11 is unclear 
> on what to do.
> > 
> > Let's consider the same scenario described above except 
> when UA1 receives a
> > BYE from UA2 after a crash (which is probably much more 
> likely). This
> > scenario extends to whenever you receive a BYE, INFO, 
> CANCEL or similar
> > post-INVITE request - whenever you would want respond with a 481 Not
> > exist(ie no call state).
> > 
> > UA1 should return a 481 request when it receives the 
> BYE/INFO/CANCEL but
> > once again if it was to place a To tag in the 481 response 
> then UA2 would
> > not be able to match the response to the request.
> > 
> > I think the spec should be clarified in Section11 as to the 
> behaviour when
> > BYE/INFO/CANCEL/etc responses are received but no call state exists.
> > Is the correct behaviour NOT to add a To tag when issuing a 
> 481? Can anyone
> > think of some way in which this will affect forking proxies 
> - I beleive it
> > should be okay as these requests do not relete to call establisment.
> > 
> > One solution that would fix all these problems is to make a From tag
> > mandatory in INVITE's (even if it is just tag=0) so that a 
> new tag will not
> > be added, however this is a fairly heavy burden.
> > 
> > Any other ideas?
> > 
> > Robert.
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 13:09:59 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01967
	for ; Thu, 20 Jul 2000 13:09:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8C38D443CD; Thu, 20 Jul 2000 13:09:18 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by lists.bell-labs.com (Postfix) with ESMTP id 476784433B
	for ; Thu, 20 Jul 2000 13:09:10 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id NAA14247
	for ; Thu, 20 Jul 2000 13:09:08 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id NAA23003; Thu, 20 Jul 2000 13:07:57 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <3NADFX07>; Thu, 20 Jul 2000 13:09:07 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: sip@lists.bell-labs.com
Date: Thu, 20 Jul 2000 13:09:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BFF26D.35C20CD0"
Subject: [SIP] SIP-H.323 Interworking Draft
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This 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_01BFF26D.35C20CD0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi, Everyone:

We are now pleased to inform that the "SIP-H.323 Interworking Requirements"
Internet-Draft has been completed. You can find the draft as follows:

        Title           : SIP-H.323 Interworking Requirements
        Author(s)       : H. Agrawal, R. R. Roy, V. Palawat, A. Johnston, C.
Agboh, K. Singh, and H. Schulzrinne
        Filename        : draft-agrawal-sip-h323-interworking-reqs-00.txt
        Pages           : 19
        Date            : 12-Jul-00

Abstract:

"This document describes the requirements for the logical entity known
as the interworking function (IWF) that will allow  the  interworking
between the SIP(Session Initiation Protocol) and H.323 networks."

This draft is expected to be presented in the 48th IETF meeting in
Pittsburgh, USA (July 31 - August 4, 2000) and may become an Informational
RFC if no future comments are received.

The next step is to produce the "SIP-H.323 Interworking" draft for producing
an IETF RFC based on this requirement draft.

Best regards,
Radhika R. Roy
AT&T



------_=_NextPart_000_01BFF26D.35C20CD0
Content-Type: text/plain;
	name="draft-agrawal-sip-h323-interworking-reqs-00.txt"
Content-Disposition: attachment;
	filename="draft-agrawal-sip-h323-interworking-reqs-00.txt"
Content-Transfer-Encoding: quoted-printable

Internet Engineering Task Force                           Hemant =
Agrawal
INTERNET DRAFT                                             GlobeSpan =
Inc
                                                          Radhika R. =
Roy
Category: Informational                                             =
AT&T
Expires: Januray 10, 2001                                  Vipin =
Palawat
                                                   Opuswave Networks =
Inc
                                                           Alan =
Johnston
                                                            MCI =
WorldCom
                                                           Charles =
Agboh
                                                 Global TeleSystem =
Group
                                                              David =
Wang
                                                Nuera Communications =
Inc
                                                            Kundan =
Singh
                                                     Henning =
Schulzrinne
                                                     Columbia =
University


                   SIP-H.323 Interworking Requirements
                


Status of this memo

This document is an Internet-Draft and is in full conformance with all  =

provisions of Section 10 of RFC2026. Internet-Drafts are working=20
documents of the Internet Engineering Task Force (IETF), its areas, and =

its working groups. Note that other groups may also distribute working=20
documents as Internet-Drafts.

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

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

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

This document is a product of the SIP-H.323 Interworking Working Group=20
of the Internet Engineering Task Force (IETF).  Comments should=20
be submitted to the mailing list sip-h323@egroups.com.


Abstract

This document describes the requirements for the logical entity known
as the interworking function (IWF) that will allow  the  interworking
between the SIP(Session Initiation Protocol) and H.323 networks.




[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page =
1]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

Table of Contents


      1.  Introduction ..............................................  =
3
      2.  Terminology ...............................................  =
3
      3.  Definitions ...............................................  =
3
      4.  Functionality within the IWF ..............................  =
3
      5.  Pre-Call Requirements .....................................  =
5
         5.1.  Registration with H.323 Gatekeeper ...................  =
5
         5.2.  Registration with SIP Server .........................  =
5
      6.  General Interworking Requirements .........................  =
6
         6.1 Basic call Requirements ................................  =
6
            6.1.1. General Requirements .............................  =
6
            6.1.2. Address Resolution ...............................  =
6
            6.1.3. Call with H.323 GK ...............................  =
6
            6.1.4. Call with SIP Servers ............................  =
7
            6.1.5. Call with both H.323 GK and SIP Server ...........  =
7
            6.1.6. Capability negotiation ...........................  =
7
            6.1.7. Opening of logical channels ......................  =
8
            6.1.8 Handling Media transmission and reception .........  =
8
         6.2. Requirements for support of fast connect procedures ...  =
8
         6.3. Requirements for support of H.245 tunnelling ..........  =
9
         6.4. Requirements for support of pre granted ARQ ...........  =
9
         6.5. Requirements for support of overlapped sending ........  =
9
         6.6. Requirements for support of early H.245 ...............  =
9
         6.7. Requirements for H.323 trunking between SIP network ...  =
9
         6.8. Requirements for SIP trunking between H.323 network ...  =
9
      7.  Transport .................................................  =
9
         7.1.  Assumptions made for underlying network ..............  =
9
         7.2.  Transport Requirements ............................... =
10
      8. Mapping between SIP and H.323 .............................. =
10
         8.1  General Procedures .................................... =
10
         8.2. H.323 Call Signalling (Q.931) and SIP Call Signalling . =
11
         8.3. H.323 Call Control (H.245) and SIP Call Control(SDP) .. =
11
         8.4. H.323 audio/video codec to SIP media formats .......... =
11
         8.5. Call sequence ......................................... =
11
      9.  State Machine Requirements ................................ =
12
     10.  Service Interoperability Requirements ..................... =
12
     11.  Security Requirements ..................................... =
12
     12.  Activities planned for next phase ......................... =
13
     13.  Examples and Scenarios .................................... =
14
     14.  Full Copyright Statement .................................. =
17
     15.  References ................................................ =
18
     16.  Acknowledgements .......................................... =
18
     17.  Authors' addresses ........................................ =
18





[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page =
2]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

1.  Introduction

This document describes the requirements for the logical entity known
as the interworking function (IWF) that will allow  the  interworking
between the SIP(Session Initiation Protocol) and H.323 networks..

2.  Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED", =
"SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in RFC 2119 [1] and=20
indicate requirement levels for the protocol.

3.  Definitions

3.1. H.323 Gatekeeper(GK)

This is an optional component in H.323 network. If it is present, it=20
must perform the address translation, bandwidth control, admission=20
control and zone management.

3.2. IWF(InterWorking Function)

It allows interworking between the H.323 and SIP system.

3.3. SIP Server=20

This can be either SIP proxy or SIP redirect server.

3.4. Endpoint=20

This is an entity from which the media originates or finally =
terminates.
This can either be H.323 terminal or SIP user agent.

3.5. Media switching fabric (MSF)=20

This is an optional logical entity present in the IWF. If it is =
present,
it will perform the task of switching RTP from one logical port to=20
other.

4. Functionality within the IWF

This section provides the functional requirements of the SIP-H.323
interworking function.

IWF can be an architecture in various ways. This may include the=20
coexistence of H.323 Gatekeeper or SIP Servers with IWF. The location =
of
the H.323 GK and/or SIP server in conjunction with the IWF is a matter=20
of implementation and not a protocol issue. There shall be no=20

[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page =
3]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000



assumptions made for the optional elements and components present in=20
either H.323 or SIP networks. The solution provided here shall work for =

a minimum configuration required for both protocols. There may be=20
recommendations for other configurations, which include optional=20
components.=20

For instance, H.323 Gatekeeper is not a mandatory component of H.323=20
network. So, there shall be no assumptions made for the basic=20
interworking which involves H.323 Gatekeeper either co-located with the =

IWF or existing separately  in the H.323 zone. IWF will belong to both=20
SIP and H.323 networks.=20

The introduction of IWF redundancy in the network is left for further
discussion.

Therefore, an IWF may  contain the following functions:=20

a) Call sequence mapping.

b) Address resolution.

c) Terminal Capability transactions. =20

d) Opening and closing of media channels.

e) Mapping media algorithms for H.323 and SIP network. =20

f) Call resource reservation and release. =20

g) Ability to provide the state of a call.

h) Call state machine.

i) Mid Call signal processing.

j) Service Interoperability Logic.

There should not be  processing of the media data at IWF. It is assumed =

that both H.323 and SIP network uses RTP as a transport for carrying=20
media. In most of the cases RTP should be flowing directly between the=20
endpoints. Even if the media from one endpoint terminates at IWF in=20
special scenario, the assumption is made that this may be simply=20
switched to another endpoint by a media switching fabric present in the =

IWF.

We are going to  use two phases in defining the interworking standard.
The first phase will define the basic call establishment and

[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page =
4]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

termination.  The second phase will include some optional, advanced=20
features, and services.  Both phases have to meet the general=20
requirements specified in the following sections.

5.  Pre-Call Requirements

The IWF function may have a table of reference for lookup to resolve =
the
corresponding H.323 and SIP addresses to IP addresses. This may be=20
accomplished by using the capabilities of either H.323 Gatekeepers or=20
SIP servers. Since H.323 Gatekeeper and SIP Server are not mandatory=20
components of H.323 and SIP systems respectively, the IWF function may=20
keep within itself the address resolution information, which may be=20
updated by using the H.323 Gatekeeper, SIP Server, or any other=20
database.

5.1.  Registration with H.323 Gatekeeper

This is done to give the information about SIP side extensions of IWF =
to
H.323 Gatekeeper if the latter is present in the network. This=20
information may be used by H.323 Gatekeeper to direct a call whose=20
destination is in the SIP network. The registration information to the=20
H.323 Gatekeeper may be updated at any time. The way in which IWF gets=20
the information about the SIP side extension is for further study.

IWF can register with one H.323 Gatekeeper only. Registration with=20
multiple gatekeepers by the IWF is for further study.

The SIP user agent may register with the H.323 Gatekeeper via the IWF.=20
To achieve this, the IWF should create an H.323 alias address for the=20
SIP=20
User agent and bind its own transport address with this alias address =20
during registration.=20

5.2.  Registration with SIP Server

This is done to give the information about H.323 side extensions of the =

IWF to the SIP Server if the latter is present in the SIP network. This =

information may be used by the SIP server to direct  a call whose=20
destination is in the H.323 network. The way in which IWF gets the=20
information  about the H.323 side extensions is for further study.=20

Since SIP does not require a gateway  for registration to the SIP=20
server, the IWF may register itself to the SIP server using TRIP[6]. =
The
IWF may register itself as a SIP User agent specifying the H.323 side=20
extensions in the REGISTER message. This IWF behavior is for further=20
discussion.

IWF may register with one or many SIP servers. This is for subsequent=20
study.

[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page =
5]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

6. General Interworking Requirements

The IWF shall use the H.323 Version 2.0 [5] and SIP Ver 2.0 [2]. The =
IWF
should handle all mandatory features of H.323 Version 2.0 as well as =
SIP
Version 2.0. It should also provide backward compatibility for earlier=20
versions.

The IWF shall provide the seamless interworking of the two protocols.=20
The functioning of IWF should not involve any modification to the H.323 =

and SIP protocols, but may involve specific profiles of these =
protocols.

6.1. Basic call Requirements

6.1.1. General Requirements

The IWF  should:

a) Provide default settings, so that the transactions will only be for =
a
change or non-default parameters. The default parameters for such=20
setting should be identified.=20

b) Release any call related resource on the detection of call=20
deactivation. SIP Session timers may be used for this purpose in SIP=20
side. However the methods for detecting call deactivation are for=20
further study.

6.1.2. Address Resolution

The IWF should:

a) Support all the addressing schemes of both H.323 and SIP protocol.

b) Register itself to H.323 Gatekeeper and SIP Server if they are=20
present in the Network.

The IWF may:

a) Have a look-up table for resolving the addresses. This may be =
updated
from the H.323 GK and SIP server.

b) Use LDAP or X.500 for keeping address resolution information.

c) Use DNS for address resolution.

d) Use TRIP

6.1.3. Call with H.323 GK=20

When an H.323 GK is present in the network, the IWF should:

[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page =
6]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

a) Resolve addresses with the help of H.323 GK.

b) Register itself to forward the SIP extensions supported on SIP side=20
of IWF.

c) Not be registered with two different H.323 Gatekeepers. This is left =

for further discussion.

The IWF may:

a) Update the newly added SIP extensions to H.323 Gatekeeper. This is=20
left for further discussion.

b) Support a SIP user agent to register to a H.323 GK

6.1.4. Call with SIP Server

When a SIP Server is present in the network, the IWF should:

a) Resolve addresses with the help of SIP Server.

The IWF may:

a) Register itself with SIP Server (e.g., using TRIP [6]) to forward =
the
H.323 extensions supported on the H.323 side of IWF.

b) Register with many SIP servers. This is left for further discussion.

c) Update the newly added H.323 extensions to SIP Server. This is left=20
for further discussion.

d) Support a H.323 endpoint (EP) to register to a SIP Server

6.1.5. Call with both H.323 GK and SIP Servers=20

All the requirements of Sections 6.1.3 and 6.1.4 will be met for this=20
case.=20

6.1.6. Capability negotiation=20

The IWF should:

a) Not make any assumptions about the capabilities of either SIP user=20
agent or H.323 terminal. However, it may indicate a default capability=20
of H.323 terminal or SIP user agent even before exchanging capability=20
with H.323(using H.245) and SIP (using SDP).  This default capability=20
follows the mandatory capability requirements as defined by the=20
respective protocols. For example, G.711 is mandatory for higher=20
bandwidth networks of H.323.

[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page =
7]




Internet draft       SIP-H.323 Interworking Requirements   10 July 2000

b) Send all the capability descriptors of H.323 and SDP descriptors of=20
SIP in the best possible way to each other. The algorithm for finding=20
out the maximum mapping of capability descriptors with the =
corresponding
SDP is left for further discussion.=20

c) Provide mapping for common audio formats supported in H.323 with the =

RTP/AVP formats.

The IWF may:

a) Use OPTIONS message on the SIP side to provide capability=20
negotiations.

b) Support re-negotiation of media capabilities.

c) Provide mapping for common video/data formats supported in H.323 =
with
the RTP/AVP formats.

6.1.7. Opening of logical channels

The IWF should:

a) Provide support for seamless exchange of messages for opening,=20
reopening, changing and closing of media channels during a call. The=20
procedures for opening, reopening, closing, and changing the existing=20
media sessions during a call are for further discussion.
=20
b) Open the channels between the endpoints wherever possible. If this =
is
not possible, then it can optionally be opened at the media switching=20
fabric of IWF.

c) Support unidirectional, symmetric bi-directional, and asymmetric bi-
directional opening of channels.

The IWF may: =20

a) Respond to the mode request and/or to the request for reopening and=20
changing an existing logical channel. .

b) Support the flow control of H.323.

6.1.8. Handle Media transmission and reception=20

The IWF shall:

a)  Not process any RTP data.

6.2. Requirements for support of fast connect procedures=20


[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page =
8]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

The IWF shall support the fast Start element in H.323.

6.3. Requirements for support of H.245 tunneling

The IWF shall support the H.245 tunneling in Setup message.

6.4. Requirements for support of pregranted ARQ=20

The IWF shall support the pre-granted ARQ. In this case, the IWF may do =

the address resolution from H.323 GK using LRQ/LCF exchange.

6.5. Requirements for support of overlapped sending=20

The IWF shall support the overlapped sending of dialed digits by using=20
the INFO method in SIP and Q.931 Setup, Setup Ack and Information=20
Message in H.323. The support for inband digit transfer (using RTP) in=20
IWF is out of scope.

The IWF shall support the transfer of digits during a call by using =
INFO
method in SIP and UserInputIndication in H.245(H.323).

6.6. Requirements for support of early H.245=20

This is left for further discussion.

6.7. Requirements for H.323 trunking between SIP networks.

This is left for next phase.

6.8. Requirements for SIP trunking between H.323 networks.

This is left for next phase.

7.  Transport=20

7.1. Assumptions made for underlying network=20

7.1.1 It should support both the TCP and UDP; i.e. both reliable and=20
non-reliable delivery of messages are supported.=20

7.1.2 The H.323 and SIP system network can be anywhere. There are no
assumptions for the closeness of these networks.

7.1.3 The network does not assure quality-of-service (QOS). The network =

that supports QOS will be addressed in the next phase.





[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page =
9]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

7.1.4 Signalling messages have no priority over other messages.

7.1.5 The Support for H.323Annex E (H.323 signaling over UDP) is=20
optional.

7.2. Media Transport Requirements=20



7.2.1 It is assumed that both H.323 and SIP network use RTP for =
carrying
media. If this is not the case, then a media gateway may be required.

7.2.2 Support for large fan-out.

8. Mapping between SIP and H.323=20

8.1. General Procedures

8.1.1. A clear mapping between SIP and H.323 messages shall be provided =

which reflects similar meaning in call sequence.

8.1.2. Call message sequence shall be maintained in both directions.

8.1.3. The IWF shall not on its own take any decision related to basic=20
functionality of a call like call setup and call teardown etc.

8.1.4. The messages that do not have a match on the other side should =
be
terminated on the IWF, and IWF should take the necessary action on them =

e.g SIP standard allows a SIP UA to silently discard an ACK for a non-
existent call leg.=20

8.1.5. In case the IWF is required to generate a message on its own in=20
any of the sides, IWF should use the pre-configured default values for=20
the parameters.

8.1.6. The information elements of the respective messages are to be=20
converted as follows:

a) The contents of connection-specific information elements (such as=20
Call Reference Value on H.323) shall be converted to respective=20
information as required by SIP or SDP (such as session ID, call leg and =

Call-ID.)

b) Information elements that are not in use on the H.323 side shall be=20
generated by the IWF as required by the SIP protocol and vice versa.

c) The SIP data fields shall be converted into the corresponding ASN.1=20
user-user information element structure. The user-user information=20
element structure shall be generated according to specifications in=20

[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
10]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

Recommendation H.225.0 version 2.0 and H.245 version 4.0.

8.2 Call Signalling (H.225.0) and SIP Call Signalling

8.2.1. The IWF shall conform to the call signalling procedures=20
recommended for the SIP side independent of the H.323 side.

8.2.2. The IWF shall conform to the call signalling procedures=20
recommended for the H.323 side independent of the SIP side.

8.2.3. The IWF shall terminate the Q.931 Call Signalling Channel =
between
an H.323 endpoint or H.323 Gatekeeper (in case of GK routed signalling) =

and the IWF on one hand and the call signalling (if any) between the =
IWF
and the SIP endpoint on the other side.

8.2.4. The IWF shall terminate the RAS Channel between H.323 Gatekeeper =

(if any) and IWF.

8.2.5. Messages for supplementary services (FACILITY, NOTIFY, and the=20
INFORMATION messages) in H.323 side may be processed by the IWF only if =

the service is supported.

8.3 H.323 Call Control (H.245) and SIP Call Control (SDP)

IWF should try to map the H.245 and SDP to the maximum extent. The list =

of messages that can be mapped is for further study.

8.4 H.323 media codec to/from SIP media formats

8.4.1. The IWF should provide invisible support for all audio =
algorithms
commonly supported by both ITU and IANA.

8.4.2. The IWF may provide invisible support for all video/data=20
algorithms commonly supported by both ITU and IANA.

8.4.3. Handling of dynamic payload types is for further discussion.

8.5. Call sequence

The call sequence on both sides should be maintained in such a way that =

neither H.323 terminal nor SIP UA is aware of the IWF presence. The IWF =

should provide seamless interworking between the call flows of the two=20
protocols. The IWF will not make any modifications to the normal call=20
flows of either protocols .The messages and parameters which do not =
have
direct mapping on the other side are to be generated by the IWF with=20
default parameters in most cases. In brief, the H.323 endpoint should=20
not be aware of the fact it is calling a SIP endpoint and vice versa.



[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
11]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

9. State Machine Requirements

The state machine for IWF will follow the following general guidelines:

9.1. Unexpected messages in a particular state shall be treated as=20
"Error" messages.

9.2. All messages which do not change the state shall be treated as =
"Non
triggering or Informational" messages.

9.3. All messages which expect a change in state shall be treated as
"Triggering" messages.

For each state, there should be guidelines that classify all possible=20
messages into the above three categories. Apart from this, it is=20
required to specify the processing i.e. action to be taken on the=20
content of the messages in the state machine.This will result in a =
table
given below as an illustration.

State : Idle

Possible Messages         Message Category   Action         Next state

All RAS Msg.              Triggering         Add Reg.Info.  =
WaitForSetup
All Q.931 Msg.            Non Triggering
All H.245 Msg.            Error=20
All Msg. from SIP side=20

10. Service Interoperability Requirements

There should be a set of interoperation scenarios and application=20
priorities. These should be defined from a service provider's point of=20
view so that the resulting solution can be used in a globally =
deployable
network that accommodates both SIP and H.323. This is an item for the=20
second phase, hence it is for further study.

11. Security Requirements

A simple security scheme should be enabled in the IWF. In this scheme=20
the IWF will accept requests from a pre-configured set of SIP Server,=20
SIP EP, H.323 EP, or H.323 GKs only and it will reject all other=20
requests.=20

All other security requirements are for further discussion. Common=20
security mechanisms between the two protocols are required to be=20
identified in the next phase.=20

Assumptions for the endpoints:


[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
12]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

11.1. All endpoints trying to use IWF are authorized with the =
respective
H.323 Gatekeepers and SIP servers if they are present in the network.=20
This is left for further discussion.

11.2. All endpoints trying to make a call using IWF are respectively
permitted to do so from H.323 Gatekeeper and SIP server if it is=20
present in the network.

Required for IWF:

11.3 Procedures for preventing denial of service security attacks.

11.4 Maintaining persistent data for authorized endpoints for future=20
verifications.

12. Activities planned for next phase

12.1 Simple call supplementary services like call forwarding, call =
hold.
and call transfer.

12.2 support for extensions of H.245 and SDP for ATM and other=20
transport.

12.3 Audio and Video Conferencing.

12.4 Session change (re-invite, mode request).

12.5 Security: Authentication, Authorization and privacy
    =20
12.6 Billing
=20
12.7 QOS signaling

12.8 Network Management

12.9 Redundancy

12.10 Support for Clearing House

12.11 Interworking with Gateway Location Protocols such as TRIP, H.225=20
AnnexG etc.

12.12 Support for fax and other data transfer(t.120 etc)

12.13 Robustness and Stability=20

12.14 H.323 trunking between SIP networks.

12.15 SIP trunking between H.323 networks.

[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
13]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

12.16 The way in which the H.323 side of the IWF gets the information=20
about the SIP side extension and vice versa for registration purpose

12.17 Registration with multiple gatekeepers or SIP servers by the IWF

12.18 Registration of the IWF itself as a SIP User Agent specifying the =

H.323 side extension in the REGISTER Message

12.19 Methods for detecting call deactivation by the IWF

12.20 The algorithm and list of messages for finding out the maximum=20
mapping of capability descriptors with corresponding SDP by the IWF

12.21 Support of early H.245 in H.323 by the IWF

12.22 Interoperation scenarios and application priorities for the=20
globally deployable network that accommodates both H.323 and SIP

12.23 Sovereignty over the IWF and relationship between the IWF (H.323=20
and SIP side) and Border Element of H.323

13. Examples and Scenarios

Here are some examples of call scenarios that will show primarily the=20
input and output signaling messages of the IWF for interworking between =

SIP and H.323. The important point is that the IWF will perform the=20
translation between the signaling messages of SIP and H.323. However, =
it
is not addressed how the mapping will be done in this contribution=20
although it is shown what should be the output signaling message of the =

IWF for a given input signaling message in the IWF.

In performing the mapping, the IWF may have to face the following
situations:

a) It may  appear that there can be one-to-one mapping between the
signaling messages; the IWF will perform the translation accordingly.

b) All parameters used in each signaling message on one side may not=20
match exactly the corresponding signaling message of the other side. In =

this situation, some manipulations need to be done by the IWF so that
an agreed-upon standard can be created based on common understanding=20
although all parameters do not exactly match.

c) For a given signaling message of a given protocol, there may not be =
a
corresponding signaling message of the other protocol that may appear =
to
be equivalent. The IWF needs to create a mapping between the signaling=20
messages or generate error messages based on common understanding of an =

agreed upon standard.


[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
14]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

Items a, b, and c as stated above are very critical to creating the =20
interoperability standard between H.323 and SIP; therefore, we would=20
like to address these in separate contributions. It may be mentioned=20
that many problems in those areas have already been addressed in the=20
interworking between SIP/SDP[2] and H.323 document [1]. However, we =
have
addressed the configurations for call scenarios and the input-output=20
messages of the IWF that are required to provide interoperability=20
between SIP and H.323.

Following are the different configurations for the call scenarios:

13.1. Basic Configuration

H.323 EP  ---- IWF ---- SIP EP

13.2. Advanced Configurations

13.2.1. Calls using H.323 GK

H.323 EP ---- H.323 GK ---- IWF ---- SIP EP

13.2.2. Calls using SIP Server

H.323 EP ---- IWF ---- SIP Server ---- SIP EP

13.2.3. Calls using both H.323 GK and SIP Server

H.323 EP ---- H.323 GK ---- IWF ---- SIP Server ---- SIP EP

13.2.4 SIP trunking between H.323 Networks

H.323 EP ------IWF-------SIP Network ------IWF---------H.323 EP

13.2.5 H.323 trunking between SIP Networks

SIP EP --------IWF-------H.323 Network --------IWF---------SIP EP

The different call scenarios for the above configurations are:

a) Simple Call from H.323 terminal to SIP terminal.	=09

b) Call from H.323 terminal to SIP terminal using H.245 tunneling.

c) Call from H.323 terminal to SIP terminal using early H.245.

d) Call from H.323 terminal to SIP terminal using fast connect=20
procedure.

e) Call from H.323 terminal to SIP terminal using overlapped sending.

[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
15]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

f) Call from H.323 terminal to SIP terminal using pre granted ARQ (for=20
configurations having H.323 GK).

g) Simple call from SIP terminal to H.323 terminal.

h) Call from SIP terminal to H.323 terminal using H.245 tunneling.

i) Call from SIP terminal to H.323 terminal using early H.245.

j) Call from SIP terminal to H.323 terminal using fast connect=20
procedure.

k) Call from SIP terminal to H.323 terminal using overlapped sending.

l) Call from SIP terminal to H.323 terminal using pregranted ARQ (for=20
configuration having H.323 GK).

m) Call from a SIP terminal to SIP terminal using H.323 trunking =
between=20
two IWFs.

n) Call from a H.323 terminal to H.323 terminal using SIP trunking=20
between two IWFs.

Some call flow examples for the different configurations and call=20
scenarios are given below:

i) Simple calls from H.323 terminal to SIP terminal using configuration
of 13.1

     H.323                        SIP
      EP    Setup   IWF           EP
       |------------>|    INVITE   |
       |             |------------>|
       |             | 180 RINGING |
       |   Alerting  |<------------|
       |<------------|   200 OK    |
       |  Connect    |<------------|
       |<------------|             |
       |   H.245     |             |
       |<----------->|    ACK      |
       |             |------------>|
       |            RTP            |
       |<------------------------->|







[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
16]




Internet draft       SIP-H.323 Interworking Requirements   10 July 2000

ii) Simple calls from SIP terminal to H.323 terminal using =
configuration=20
of 13.1

   SIP                        H.323
    EP           IWF            EP
    |             |             |
    |   INVITE    |             |
    |------------>|   Setup     |
    |             |------------>|
    |             |  Alerting   |
    | 180 RINGING |<------------|
    |<------------|   Connect   |
    |             |<------------|
    |             |    H.245    |       =20
    |     200 OK  |<----------->|
    |<------------|             |
    |     ACK     |             |
    |------------>|             |   =20
    |            RTP            |
    |<------------------------->|


14.  Full Copyright Statement

Copyright (C) The Internet Society (1999, 2000). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns .

This document and the information contained herein is provided on an =
"AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR =
FIT-
NESS FOR A PARTICULAR PURPOSE."


[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
17]




Internet draft       SIP-H.323 Interworking Requirements   10 July 2000

15.  References

[1] Singh/Schulzrinne, "Interworking Between SIP/SDP and H.323", draft-
singh-sip-h323-00.txt,IETF, January 2000.

[2] M. Handley, H.Schulzrinne, E.Schooler, and J.Rosenberg, =
"SIP:Session=20
Initiation Prtocol", RFC 2543,IETF,March 1999.

[3] M. Handley and V. Jacobson, "SDP: Session Description Prtocol", RFC =

2327, IETF, April 1998.

[4] S. Bradner,"Key words for use in RFCs to indicate requirement=20
levels", RFC 2119,IETF, March 1997.

[5] "Packet based multimedia communication systems", Recommendation=20
H.323,ITU-T,Geneva,Switzerland,Feb. 1998.

[6]  J.Rosenberg and H.Salama, "Usage of TRIP in Gateways for Exporting =

Phone Routes",draft-rs-trip-gw-00.txt, IETF, March 2000.

[7]  H.Agrawal, R.R.Roy, V.Palawat, "SIP-H.323 Interworking=20
Requirements", draft-agrawal-roy-palawat-sip-h323-interworking-reqs-
00.txt, IETF, April 2000.

16.  Acknowledgements

The authors would like to acknowledge the many contributors who debated
the SIP-H.323 interworking architecture and requirements on the IETF ,
SIP and SG16 mailing lists. Contributions to this document have also
been made through internet-drafts and discussion with members of SIP,
H.323, aHIT!, TIPHON and SG16 forums.

17.  Authors' addresses

        Hemant Agrawal
        GlobeSpan Inc.
        A-8, Sector 9,
        Noida (U.P.) - 201 301=20
        INDIA
        Tel: +91-575-4544028/4132 Extn: 121
        Fax: +91-575-4544014
        Email: hemantag@globespan.net

        Radhika R. Roy
        AT&T
        Room C1-2B03
        200 Laurel Avenue S.
        Middletown,
        NJ 07748,=20
       =20
[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
18]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000

        USA
        Tel: +1-732-4201580
        Fax: +1-732-3681195
        Email: rrroy@att.com

        Vipin Palawat
        Opuswave Networks Inc.
        1365, Garden Of Gods Road,
        Colorado Springs, CO 80907
        USA
        Tel: +1-719-955-7427
        Fax: +1-719-548-8658
        Email: vpalawat@opuswave.com

        David Wang
        Nuera Communications Inc.
        10445 Pacific Center Court
        San Diego, CA 92121
        USA
        Tel: +1 858 625 9220 x 1260
        Fax: +1 858 625 2422
        Email: dwang@nuera.com

        Alan Johnston
        MCI WorldCom
        100 South Fourth Street
        St. Louis, MO 63102
        USA
        Tel: +1 314 342 73 60
        Fax: +1 314 342 8452
        Email: alan.johnston@wcom.com

        Charles Agboh
        Global TeleSystem Group
        Terhulsesteenweg 6A,=20
        1560 Hoeilaart
        Belgium.
        Tel: +3 22 658 42 43,
        Fax: +3 22 658 51 18
        Email: Charles.Agboh@gtsgroup.com

        Kundan Singh
        Dept. of Computer Science
        Columbia University
        1214 Amsterdam Avenue, MC 0401
        New York, NY 10027
        USA
        Email: kns10@cs.columbia.edu


[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
19]




Internet draft       SIP-H.323 Interworking Requirements    10 July =
2000 =20

        Henning Schulzrinne
        Dept. of Computer Science
        Columbia University
        1214 Amsterdam Avenue, MC 0401
        New York, NY 10027
        USA
        Email: schulzrinne@cs.columbia.edu=20











































[Agarwal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page =
20]=20


------_=_NextPart_000_01BFF26D.35C20CD0--


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 13:35:01 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16030
	for ; Thu, 20 Jul 2000 13:35:00 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D4D0B443C3; Thu, 20 Jul 2000 13:34:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from turin.trillium.com (unknown [38.187.146.197])
	by lists.bell-labs.com (Postfix) with ESMTP id ACD61443AA
	for ; Thu, 20 Jul 2000 13:34:45 -0400 (EDT)
Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id  for ;
 Thu, 20 Jul 2000 10:49:19 -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19])
	by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id KAA10143
	for ; Thu, 20 Jul 2000 10:34:41 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 20 Jul 2000 10:30:06 -0700
Message-ID: <8BBD33A986C5D311804000902719FF5DC099BE@aega.trillium.com>
From: Aseem Agarwal 
To: sip@lists.bell-labs.com
Date: Thu, 20 Jul 2000 10:29:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Question on SIP IDs
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi All,
   I am looking for the updated versions and status of the following 
   SIP related Internet Drafts :

1. MIME types for ISUP message (draft-watson-sip-isup-mime-00.txt) 
   expired in April 2000
2. Establishing QOS and security preconditions for SDP Sessions
   (draft-ietf-mmusic-sdp-qos-00.txt)
   expired Dec 1999
3. SIP 183 Session Progress Message (draft-ietf-sip-183-00.txt)
   expired in April 2000
   
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  Thu Jul 20 13:57:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27559
	for ; Thu, 20 Jul 2000 13:57:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A5597443CD; Thu, 20 Jul 2000 13:56:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 3864E4433B
	for ; Thu, 20 Jul 2000 13:56:42 -0400 (EDT)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA05070;
	Thu, 20 Jul 2000 10:56:54 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAB04845;
	Thu, 20 Jul 2000 10:56:39 -0700 (PDT)
Message-Id: <4.2.0.58.20000720104158.01c0f8c0@lint.cisco.com>
X-Sender: rmahy@lint.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 20 Jul 2000 10:55:55 -0700
To: wtm@research.bell-labs.com, jdrosen@dynamicsoft.com
From: Rohan Mahy 
Cc: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] draft-manyfolks & use of 180 Ringing plus Session: qos
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,

I asked about use of 180 with the Session header back on the list before 
Adelaide and raised this as an issue there.  Jonathan agreed that 180 + 
Session: QoS was acceptable, and I did not hear any technical objection to 
its use.

The latest draft-manyfolks still references only 183/PRACK/200, COMET/200, 
then another round of 180/PRACK/200.  Permitting 180/PRACK/200 as an option 
would save a round of signaling for calls to native SIP phones, and I 
cannot see any negative effects.

Can you please incorporate this as an option in the next version of this 
document?  I am happy to provide sample flows.

thanks,
-rohan


 >>Date: Wed, 22 Mar 2000 19:22:32 -0800
 >>To: Jonathan Rosenberg 
 >>From: Rohan Mahy 
 >>Subject: Re: clarifications on 183 and "manyfolks" drafts
 >>Cc: William Marshall , 
sip@lists.research.bell-labs.com
 >>
 >>At 09:23 PM 3/21/00 , Jonathan Rosenberg wrote:
 >>
 >>I am in agreement with Bill's assessment here. The idea is to keep the
 >>precondition mechanism independent of the underlying QoS protocol.
 >>
 >>However, I disagree that the Session header only makes sense for 183. I
 >>see no reason why. My view of the Session header is that it informs the
 >>UA that there is some dependency on signaling behavior because of the
 >>session. The QoS and security Session: tokens in a request indicate that
 >>the INVITE should not cause local alerting until the preconditions are
 >>met, and that a provisional response with SDP should be sent. The QoS
 >>and security Session: in the provisional response indicates a similar
 >>thing - don't do anything with this message until the preconditions are
 >>met. So, I would argue its OK to put a Session header in a 180, in which
 >>case ringing (signaled by 180) doesn't occur until the preconditions are
 >>met.
 >>
 >great.  this could save a whole cycle of 183/ PRACK/ 200 messages in some
 >circumstances.




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


From sip-admin@lists.bell-labs.com  Thu Jul 20 13:58:37 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28402
	for ; Thu, 20 Jul 2000 13:58:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6EFFC443DE; Thu, 20 Jul 2000 13:57:58 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id EF737443D9
	for ; Thu, 20 Jul 2000 13:57:51 -0400 (EDT)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA06182
	for ; Thu, 20 Jul 2000 10:58:05 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAB04867;
	Thu, 20 Jul 2000 10:57:48 -0700 (PDT)
Message-Id: <4.2.0.58.20000720105603.01bc9450@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 20 Jul 2000 10:57:04 -0700
To: sip@lists.bell-labs.com
From: Rohan Mahy 
Subject: 2nd: [SIP] harmonized SUBSCRIBE/NOTIFY behavior
In-Reply-To: <4.2.0.58.20000706104920.00de0af0@lint.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,

Would anyone care to comment on this, or should this become a SIP LIST OPEN 
ISSUE?

thanks,
-rohan

At 12:16 PM 7/6/00 , Rohan Mahy wrote:

>Hi,
>
>I'm looking for some consistent direction on SUBSCRIBE/NOTIFY.  Since we 
>have the SUBSCRIBE/NOTIFY draft, PINT, and IMPP for presence, all doing 
>stuff differently.
>
>I can see valid reasons for each of these cases:
>
>a       subscribe to ongoing state, I already know the current state
>b       subscribe to ongoing state, plus get current state
>c       refresh subscription, I know the current state
>d       refresh subscription, plus get current state
>e       fetch the current state
>f       unsubscribe
>
>Hopefully Jonathan Rosenberg, Scott Petrack, and Adam Roach have all 
>talked about this somewhere.
>My interetation of the currently available documents is that they can do this:
>
>SUB/NFY a, c, f
>PINT            a, c, e, f
>IMPP            b, c, e, f
>
>Perhaps we need a new header/parameter used in a SUBSCRIBE that indicates 
>whether to send back immediate status?
>
>Also, the use of an Event header, Call-ID usage, and body handling are not 
>consistent, but this seems like less of an issue.
>
>Anyone care to clarify?  Will the three documents be harmonized (apologies 
>for using an ITU term) at some point?
>
>Relevant sections of the documents are included below.  Also, a short 
>comment on IMPP inline...
>
>thanks,
>-rohan
>
>
>In draft-roach-sip-subscribe-notify-00.txt, the author asks:
>
>>Should cancelling a subscription be performed with the UNSUBSCRIBE method 
>>defined in PINT for the sake of consistency, or is the REGISTER model of 
>>"Expires: 0" preferable?
>
>There is no mention of the SUBSCRIBE response carrying back any state.  In 
>the companion document, draft-roach-sip-acb-00.txt, a SUBSCRIBE to the 
>"terminal-free" event does not necessarily need state in the reply, 
>because presumably, the subscriber already assumed the terminal wan't 
>free, because they got a busy signal.
>
>In RFC2848, the authors state:
>
>>When a SUBSCRIBE request is sent to a PINT Server, it indicates that a 
>>user wishes to receive information about the status of a service session. 
>>The request identifies the session of interest by including the original 
>>session description along with the request, using the SDP 
>>global-session-id that forms part of the origin-field to identify the 
>>service session uniquely.
>
>>Rather than have two different methods of identifying the "session of 
>>interest" the choice is to use the origin-field of the SDP sub-part 
>>included both in the original INVITE and in this SUBSCRIBE request.
>>
>>Note that the request MUST NOT include any sub-parts other than the 
>>session description, even if these others were present in the original 
>>INVITE request. A server MUST ignore whatever sub-parts are included 
>>within a SUBSCRIBE request with the sole exception of the enclosed 
>>session description. The request MAY contain a "Contact:" header, 
>>specifying the PINT User Agent Server to which such information should be sent.
>>
>>In addition, it SHOULD contain an Expires: header, which indicates for 
>>how long the PINT Requestor wishes to receive notification of the session 
>>status. We refer to the period of time before the expiration of the 
>>SUBSCRIBE request as the "subscription period". See section 5.1.4.  for 
>>security considerations, particularly privacy implications.
>>
>>A value of 0 within the Expires: header indicates a desire to receive one 
>>single immediate response (i.e. the request expires immediately). It is 
>>possible for a sequence of monitoring sessions to be opened, exist, and 
>>complete, all relating to the same service session.
>>
>>A successful response to the SUBSCRIBE request includes the session 
>>description, according to the Gateway. Normally this will be identical to 
>>the last cached response that the Gateway returned to any request 
>>concerning the same SDP global session id (see [2], section 6, o= field). 
>>The t= line may be altered to indicate the actual start or stop time, 
>>however. The Gateway might add an i= line to the session description to 
>>indicate such information as how many fax pages were sent. The Gateway 
>>SHOULD include an Expires: header indicating how long it is willing to 
>>maintain the monitoring session. If this is unacceptable to the PINT 
>>Requestor, then it can close the session by sending an immediate 
>>UNSUBSCRIBE message (see 3.5.3.3).
>
>
>>At some point, either the Client's representative User Agent Server or 
>>the Gateway may decide to terminate the monitoring session. This is 
>>achieved by sending an UNSUBSCRIBE request to the correspondent 
>>server.  Such a request indicates that the sender intends to close the 
>>monitoring session immediately, and, on receipt of the final response 
>>from the receiving server, the session is deemed over.
>>
>>Note that unlike the SUBSCRIBE request, which is never sent by a PINT 
>>gateway, an UNSUBSCRIBE request can be sent by a PINT gateway to the User 
>>Agent Server to indicate that the monitoring session is closed. (This is 
>>analogous to the fact that a gateway never sends an INVITE, although it 
>>can send a BYE to indicate that a telephone call has ended.)
>>
>>If the Gateway initiates closure of the monitoring session by sending an 
>>UNSUBSCRIBE message, it SHOULD include an "Expires:" header showing for 
>>how much longer after this monitoring session is closed it is willing to 
>>store information on the service session. This acts as a minimum time 
>>within which the Client can send a new SUBSCRIBE message to open another 
>>monitoring session; after the time indicated in the Expires: header the 
>>Gateway is free to dispose of any record of the service session, so that 
>>subsequent SUBSCRIBE requests can be rejected with a "606" response.
>>
>>If the subscription period specified by the Client has expired, then the 
>>Gateway may send an immediate UNSUBSCRIBE request to the Client's 
>>representative User Agent Server. This ensures that the monitoring 
>>session always completes with a UNSUBSCRIBE/response exchange, and that 
>>the representative User Agent Server can avoid maintaining state in 
>>certain circumstances.
>
>
>In draft-rosenberg-impp-presence-00.txt, the authors state:
>
>>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.
>
>Jonathan, instead of the first sentence I propose something like this:
>
>"A SUBSCRIBE request MUST contain a Contact header, unless the SUBSCRIBE 
>request is used for Fetching currect state only (see section 5.8)."     OR
>
>"An ordinary SUBSCRIBE request MUST contain a Contact header.  A SUBSCRIBE 
>request without a Contact is used for Fetching current state only, and 
>does not cause notifications."
>
>>[When replying to a new subscription,] The 200 OK response SHOULD also 
>>contain a copy of the current presence state of the presentity.
>
>>A subscriber may unsubscribe by sending a SUBSCRIBE request with an 
>>Expires header of 0. The Contact header indicates the particular address 
>>that is being unsubscribed. This MAY be a *, indicating that all Contacts 
>>for that particular subscription (as identified by the Call-ID, To, and 
>>From) are to be removed. If all Contacts are removed, the PA deletes the 
>>subscription.
>
>>Fetching is similar to a subscribing, in that it returns the current 
>>presence state. However, no notifications are sent for future changes in 
>>the presence state. Rather than inventing a new method for this, it is 
>>readily accomplished with a SUBSCRIBE along with an Expires: 0 header and 
>>no Contact header. The absence of any Contact header is what 
>>distinguishes it from the similar operation of unsubscribing. The 
>>advantage of using SUBSCRIBE is that the server can simply process the 
>>request independently of whether its a fetch or longer lived 
>>subscription; the authorization and processing steps are identical. The 
>>only difference is whether an actual subscription is instantiated for the 
>>user or not.
>>
>>This parallels how fetching of registrations is done in SIP. Note that 
>>fetching has no effect on existing subscriptions.
>
>
>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  Thu Jul 20 14:13:07 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06710
	for ; Thu, 20 Jul 2000 14:13:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ADDCB443D9; Thu, 20 Jul 2000 14:12:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8B90B4433B
	for ; Thu, 20 Jul 2000 14:11:58 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA24741;
	Thu, 20 Jul 2000 14:13:19 -0400 (EDT)
Message-ID: <397741C4.6B32C4CC@dynamicsoft.com>
Date: Thu, 20 Jul 2000 14:15:32 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rohan Mahy 
Cc: sip@lists.bell-labs.com
Subject: Re: 2nd: [SIP] harmonized SUBSCRIBE/NOTIFY behavior
References: <4.2.0.58.20000720105603.01bc9450@lint.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I responded on the sip-events list, but there wasn't any comment on my
response.

Anyway, this needs to be resolved. Its a big issue that probably will
take more time than is available during the meeting. I would propose an
informal gather at the bar to discuss. If you are interested in coming
to such a gathering, let me know.

I would also like to propose a similar gathering to talk about
directions for multiparty conferencing, another big issue that needs
discussion in real time, but will take too much time to be done in the
meeting itself.

Of course, notes from both informal gatherings will be made available,
and any agreements arrived at are, as always, subject to wg review and
acceptance/rejection.

-Jonathan R.

Rohan Mahy wrote:
> 
> Hi,
> 
> Would anyone care to comment on this, or should this become a SIP LIST OPEN
> ISSUE?
> 
> thanks,
> -rohan
> 
> At 12:16 PM 7/6/00 , Rohan Mahy wrote:
> 
> >Hi,
> >
> >I'm looking for some consistent direction on SUBSCRIBE/NOTIFY.  Since we
> >have the SUBSCRIBE/NOTIFY draft, PINT, and IMPP for presence, all doing
> >stuff differently.
> >
> >I can see valid reasons for each of these cases:
> >
> >a       subscribe to ongoing state, I already know the current state
> >b       subscribe to ongoing state, plus get current state
> >c       refresh subscription, I know the current state
> >d       refresh subscription, plus get current state
> >e       fetch the current state
> >f       unsubscribe
> >
> >Hopefully Jonathan Rosenberg, Scott Petrack, and Adam Roach have all
> >talked about this somewhere.
> >My interetation of the currently available documents is that they can do this:
> >
> >SUB/NFY a, c, f
> >PINT            a, c, e, f
> >IMPP            b, c, e, f
> >
> >Perhaps we need a new header/parameter used in a SUBSCRIBE that indicates
> >whether to send back immediate status?
> >
> >Also, the use of an Event header, Call-ID usage, and body handling are not
> >consistent, but this seems like less of an issue.
> >
> >Anyone care to clarify?  Will the three documents be harmonized (apologies
> >for using an ITU term) at some point?
> >
> >Relevant sections of the documents are included below.  Also, a short
> >comment on IMPP inline...
> >
> >thanks,
> >-rohan
> >
> >
> >In draft-roach-sip-subscribe-notify-00.txt, the author asks:
> >
> >>Should cancelling a subscription be performed with the UNSUBSCRIBE method
> >>defined in PINT for the sake of consistency, or is the REGISTER model of
> >>"Expires: 0" preferable?
> >
> >There is no mention of the SUBSCRIBE response carrying back any state.  In
> >the companion document, draft-roach-sip-acb-00.txt, a SUBSCRIBE to the
> >"terminal-free" event does not necessarily need state in the reply,
> >because presumably, the subscriber already assumed the terminal wan't
> >free, because they got a busy signal.
> >
> >In RFC2848, the authors state:
> >
> >>When a SUBSCRIBE request is sent to a PINT Server, it indicates that a
> >>user wishes to receive information about the status of a service session.
> >>The request identifies the session of interest by including the original
> >>session description along with the request, using the SDP
> >>global-session-id that forms part of the origin-field to identify the
> >>service session uniquely.
> >
> >>Rather than have two different methods of identifying the "session of
> >>interest" the choice is to use the origin-field of the SDP sub-part
> >>included both in the original INVITE and in this SUBSCRIBE request.
> >>
> >>Note that the request MUST NOT include any sub-parts other than the
> >>session description, even if these others were present in the original
> >>INVITE request. A server MUST ignore whatever sub-parts are included
> >>within a SUBSCRIBE request with the sole exception of the enclosed
> >>session description. The request MAY contain a "Contact:" header,
> >>specifying the PINT User Agent Server to which such information should be sent.
> >>
> >>In addition, it SHOULD contain an Expires: header, which indicates for
> >>how long the PINT Requestor wishes to receive notification of the session
> >>status. We refer to the period of time before the expiration of the
> >>SUBSCRIBE request as the "subscription period". See section 5.1.4.  for
> >>security considerations, particularly privacy implications.
> >>
> >>A value of 0 within the Expires: header indicates a desire to receive one
> >>single immediate response (i.e. the request expires immediately). It is
> >>possible for a sequence of monitoring sessions to be opened, exist, and
> >>complete, all relating to the same service session.
> >>
> >>A successful response to the SUBSCRIBE request includes the session
> >>description, according to the Gateway. Normally this will be identical to
> >>the last cached response that the Gateway returned to any request
> >>concerning the same SDP global session id (see [2], section 6, o= field).
> >>The t= line may be altered to indicate the actual start or stop time,
> >>however. The Gateway might add an i= line to the session description to
> >>indicate such information as how many fax pages were sent. The Gateway
> >>SHOULD include an Expires: header indicating how long it is willing to
> >>maintain the monitoring session. If this is unacceptable to the PINT
> >>Requestor, then it can close the session by sending an immediate
> >>UNSUBSCRIBE message (see 3.5.3.3).
> >
> >
> >>At some point, either the Client's representative User Agent Server or
> >>the Gateway may decide to terminate the monitoring session. This is
> >>achieved by sending an UNSUBSCRIBE request to the correspondent
> >>server.  Such a request indicates that the sender intends to close the
> >>monitoring session immediately, and, on receipt of the final response
> >>from the receiving server, the session is deemed over.
> >>
> >>Note that unlike the SUBSCRIBE request, which is never sent by a PINT
> >>gateway, an UNSUBSCRIBE request can be sent by a PINT gateway to the User
> >>Agent Server to indicate that the monitoring session is closed. (This is
> >>analogous to the fact that a gateway never sends an INVITE, although it
> >>can send a BYE to indicate that a telephone call has ended.)
> >>
> >>If the Gateway initiates closure of the monitoring session by sending an
> >>UNSUBSCRIBE message, it SHOULD include an "Expires:" header showing for
> >>how much longer after this monitoring session is closed it is willing to
> >>store information on the service session. This acts as a minimum time
> >>within which the Client can send a new SUBSCRIBE message to open another
> >>monitoring session; after the time indicated in the Expires: header the
> >>Gateway is free to dispose of any record of the service session, so that
> >>subsequent SUBSCRIBE requests can be rejected with a "606" response.
> >>
> >>If the subscription period specified by the Client has expired, then the
> >>Gateway may send an immediate UNSUBSCRIBE request to the Client's
> >>representative User Agent Server. This ensures that the monitoring
> >>session always completes with a UNSUBSCRIBE/response exchange, and that
> >>the representative User Agent Server can avoid maintaining state in
> >>certain circumstances.
> >
> >
> >In draft-rosenberg-impp-presence-00.txt, the authors state:
> >
> >>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.
> >
> >Jonathan, instead of the first sentence I propose something like this:
> >
> >"A SUBSCRIBE request MUST contain a Contact header, unless the SUBSCRIBE
> >request is used for Fetching currect state only (see section 5.8)."     OR
> >
> >"An ordinary SUBSCRIBE request MUST contain a Contact header.  A SUBSCRIBE
> >request without a Contact is used for Fetching current state only, and
> >does not cause notifications."
> >
> >>[When replying to a new subscription,] The 200 OK response SHOULD also
> >>contain a copy of the current presence state of the presentity.
> >
> >>A subscriber may unsubscribe by sending a SUBSCRIBE request with an
> >>Expires header of 0. The Contact header indicates the particular address
> >>that is being unsubscribed. This MAY be a *, indicating that all Contacts
> >>for that particular subscription (as identified by the Call-ID, To, and
> >>From) are to be removed. If all Contacts are removed, the PA deletes the
> >>subscription.
> >
> >>Fetching is similar to a subscribing, in that it returns the current
> >>presence state. However, no notifications are sent for future changes in
> >>the presence state. Rather than inventing a new method for this, it is
> >>readily accomplished with a SUBSCRIBE along with an Expires: 0 header and
> >>no Contact header. The absence of any Contact header is what
> >>distinguishes it from the similar operation of unsubscribing. The
> >>advantage of using SUBSCRIBE is that the server can simply process the
> >>request independently of whether its a fetch or longer lived
> >>subscription; the authorization and processing steps are identical. The
> >>only difference is whether an actual subscription is instantiated for the
> >>user or not.
> >>
> >>This parallels how fetching of registrations is done in SIP. Note that
> >>fetching has no effect on existing subscriptions.
> >
> >
> >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

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


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 14:23:18 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11644
	for ; Thu, 20 Jul 2000 14:23:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1F0BF443E6; Thu, 20 Jul 2000 14:22:19 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1C73E443DA
	for ; Thu, 20 Jul 2000 14:22:15 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA24850;
	Thu, 20 Jul 2000 14:23:37 -0400 (EDT)
Message-ID: <3977442E.74E455B8@dynamicsoft.com>
Date: Thu, 20 Jul 2000 14:25:50 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Aseem Agarwal 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Question on SIP IDs
References: <8BBD33A986C5D311804000902719FF5DC099BE@aega.trillium.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Aseem Agarwal wrote:
> 
> Hi All,
>    I am looking for the updated versions and status of the following
>    SIP related Internet Drafts :
> 
> 1. MIME types for ISUP message (draft-watson-sip-isup-mime-00.txt)
>    expired in April 2000

http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-03.txt


> 2. Establishing QOS and security preconditions for SDP Sessions
>    (draft-ietf-mmusic-sdp-qos-00.txt)
>    expired Dec 1999

http://search.ietf.org/internet-drafts/draft-manyfolks-sip-resource-01.txt

> 3. SIP 183 Session Progress Message (draft-ietf-sip-183-00.txt)
>    expired in April 2000


yes, this seems to have expired. I believe we decided to fold the 183
response code itself into the bis draft; it was just the Session header
we needed to work on.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 17:45:39 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22315
	for ; Thu, 20 Jul 2000 17:45:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 82A2D443D7; Thu, 20 Jul 2000 17:44:55 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id C980844340
	for ; Thu, 20 Jul 2000 17:44:47 -0400 (EDT)
Received: (qmail 19872 invoked by uid 1002); 20 Jul 2000 21:41:30 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14711.29193.815764.324729@jodie.lucid>
Date: Fri, 21 Jul 2000 00:41:29 +0300 (IDT)
To: SIP 
X-Mailer: VM 6.62 under Emacs 19.34.1
Reply-To: Dvir Oren 
Subject: [SIP] BYE at the callee through proxies
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I don't understand to whom a callee should send its
BYE to.  Should it do a user lookup on the From 
SIP URL?  What happens if there are any proxies
that need to be informed along the way?

For the caller - this is simple.  It receives
the Record-Route, which is then translated to
Route on the ACK, and can be saved for the BYE
(Though this may be implementation difficult
since after sending the ACK, it should have removed
the first Record-Route, though it needs it for the 
BYE).

But the callee theoretically doesn't have this
information.  By the time it receives the ACK,
there will be no Route information.  It can,
save the Record-Route information from the
200 Success, and then turn it into Route 
(without reversing the order), though I don't
see this in the RFC.

It seems like the only thing a callee knows
is either the From SIP URL (what happens if
the URL is incorrect, or the hostname there is
not known at the callee?), in which case it will
have to do a user lookup to find how to reach the URL,
and hopefully it will travel through the same procies,
though not necessarily.  Or it has saved the Contact
that the caller gave it (if it gave a Contact), in
which case the BYE will definitely not travel
through the proxies.  Or it can try to use the 
Record-Route information, which will
contain the wrong user!

Can anybody tell me how is the callee supposed to know
to whom to send the BYE to?

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 17:47:23 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23140
	for ; Thu, 20 Jul 2000 17:47:23 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BE50444340; Thu, 20 Jul 2000 17:47:19 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 9595F4433B
	for ; Thu, 20 Jul 2000 17:47:13 -0400 (EDT)
Received: (qmail 19875 invoked by uid 1002); 20 Jul 2000 21:44:10 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14711.29353.987564.881674@jodie.lucid>
Date: Fri, 21 Jul 2000 00:44:09 +0300 (IDT)
To: SIP 
X-Mailer: VM 6.62 under Emacs 19.34.1
Reply-To: Dvir Oren 
Subject: [SIP] Display Name
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

This may be a dumb questions, but I was wondering
when are you supposed to put quotes around
a display name?  Am I guaranteed to have 
quotes around a name with spaces?  Can I
discard spaces in a name without quotes?

How should I treat a Display Name like this:
From:  This      is
  My
     Name <...>

?
Can I treat it as "This is My Name" <...>?

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 17:56:42 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27262
	for ; Thu, 20 Jul 2000 17:56:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B4283443E6; Thu, 20 Jul 2000 17:55:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 0FF1E443D0
	for ; Thu, 20 Jul 2000 17:55:40 -0400 (EDT)
Received: (qmail 19878 invoked by uid 1002); 20 Jul 2000 21:52:36 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14711.29860.208804.340373@jodie.lucid>
Date: Fri, 21 Jul 2000 00:52:36 +0300 (IDT)
To: SIP 
X-Mailer: VM 6.62 under Emacs 19.34.1
Reply-To: Dvir Oren 
Subject: [SIP] Local Calls
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I'm asking again because I did not get an
answer last time.  Perhaps I didn't explain myself
very clearly.  I realize that this is somewhat
of an implementation issue, however I was
hoping for a standardized solution.

Suppose I have a SIP Telephone that has
2 lines.  The SIP Implementation has a 
UAC and a UAS, which both share their
"call database".

How do I make a call between line 1 and line 2?
The UAC will send the INVITE to the UAS
through loopback.

The UAS will now go over the "call database"
to see if this is an INVITE retransmission.
It will find there the call that the UAC has placed
there with EXACTLY the same headers
as the INVITE that it received.
The same Call-ID, the same 'To', 'Form',
'C-Seq'.  In fact, it will be the
same exact message.  It can even compare
it byte by byte, and it will be the same.

Is there a solution for this?

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 18:56:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24273
	for ; Thu, 20 Jul 2000 18:56:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 702F4443DE; Thu, 20 Jul 2000 18:56:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204])
	by lists.bell-labs.com (Postfix) with ESMTP id 199AA4433B
	for ; Thu, 20 Jul 2000 18:56:11 -0400 (EDT)
Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id SAA23809;
	Thu, 20 Jul 2000 18:55:51 -0400 (EDT)
Message-ID: <39778379.931BBCA3@cisco.com>
Date: Thu, 20 Jul 2000 18:55:53 -0400
From: Shail Bhatnagar 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Record-Route and maddr
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Let us say proxy "proxy.domain.com" listening at port 5060 receives
this request :

INVITE sip:abc@xyz.com SIP/2.0

and it introduces a Record-Route header.
My question is should the Record-Route look like :



or 



On a related note, what should proxies do with maddr parameter in
the incoming request-URI ( the request may or may not have a Route).


My third question is about the following statement in section 4.3

"The host portion of the Request-URI typically agrees with one of 
the host names of the receiving server. If it does not the proxy
SHOULD proxy the request to the address indicated or return a 404..."

As per the above statement, if the proxy "proxy.domain.com" at port
5060 gets the following request :

INVITE sip:abc@proxy.domain.com:5055 SIP/2.0

it would try to lookup user abc instead of forwarding the request
on the local machine to port 5055. Is it okay to do this ??

-- 
Best regards,
Shail


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 21:21:39 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19506
	for ; Thu, 20 Jul 2000 21:21:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 56A3F443BF; Thu, 20 Jul 2000 21:20:54 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id 61D454433B
	for ; Thu, 20 Jul 2000 21:20:47 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7J19W9>; Thu, 20 Jul 2000 18:21:17 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Dvir Oren'" , SIP 
Subject: RE: [SIP] BYE at the callee through proxies
Date: Thu, 20 Jul 2000 18:21:11 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Dvir,

The Caller MUST put a Contact in the INVITE request so the callee should
send the BYE to that address - unless there was a Record-Route present in
the INVITE (in which case the BYE is sent to the nearest Route address as
per the RFC).

Robert.

PS. I sent a reply to you on the Local Calls - you just didn't like it.

-- My opinions are my own. I tried selling them once but everybody seems
	to already have one. -- 

> -----Original Message-----
> From: Dvir Oren [mailto:dvir@lucidvon.com]
> Sent: Friday, July 21, 2000 5:41 AM
> To: SIP
> Subject: [SIP] BYE at the callee through proxies
> 
> 
> I don't understand to whom a callee should send its
> BYE to.  Should it do a user lookup on the From 
> SIP URL?  What happens if there are any proxies
> that need to be informed along the way?
> 
> For the caller - this is simple.  It receives
> the Record-Route, which is then translated to
> Route on the ACK, and can be saved for the BYE
> (Though this may be implementation difficult
> since after sending the ACK, it should have removed
> the first Record-Route, though it needs it for the 
> BYE).
> 
> But the callee theoretically doesn't have this
> information.  By the time it receives the ACK,
> there will be no Route information.  It can,
> save the Record-Route information from the
> 200 Success, and then turn it into Route 
> (without reversing the order), though I don't
> see this in the RFC.
> 
> It seems like the only thing a callee knows
> is either the From SIP URL (what happens if
> the URL is incorrect, or the hostname there is
> not known at the callee?), in which case it will
> have to do a user lookup to find how to reach the URL,
> and hopefully it will travel through the same procies,
> though not necessarily.  Or it has saved the Contact
> that the caller gave it (if it gave a Contact), in
> which case the BYE will definitely not travel
> through the proxies.  Or it can try to use the 
> Record-Route information, which will
> contain the wrong user!
> 
> Can anybody tell me how is the callee supposed to know
> to whom to send the BYE to?
> 
> -- 
> Dvir Oren               
> Lucid VON Ltd.     
> 9 Saloniki St.,        Tel-Aviv       Israel
> Tel:  +972 3 644 3038  Fax:  +972 3 644 3039
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


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


From sip-admin@lists.bell-labs.com  Thu Jul 20 21:25:53 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20871
	for ; Thu, 20 Jul 2000 21:25:53 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9B16F443D7; Thu, 20 Jul 2000 21:25:30 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id 9C2C4443B8
	for ; Thu, 20 Jul 2000 21:25:26 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id VAA06436; Thu, 20 Jul 2000 21:25:23 -0400 (EDT)
Message-ID: <03c501bff2b3$0d6eb490$3102a8c0@broadsoft.com>
From: "Brett Tate" 
To: "Fairlie-Cuninghame, Robert" ,
        "'Henning Schulzrinne'" 
Cc: 
References: 
Subject: Re: [SIP] Adding tags across reboots.
Date: Thu, 20 Jul 2000 21:29:02 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

The best thing to do is add a tag in the From header 
of the original INVITE.  And yes I wish that it was 
mandatory or that RFC2543 mention the 
potential for problems if the tag isn't added.

Another way is to set the Contact header of the 
original INVITE to be of a value which would 
distinguish an incoming re-INVITE from incoming 
INVITE.

----- Original Message ----- 
From: Fairlie-Cuninghame, Robert 
To: 'Henning Schulzrinne' 
Cc: 
Sent: Thursday, July 20, 2000 12:16 PM
Subject: RE: [SIP] Adding tags across reboots.


> But in the scenario I described you would still be adding a tag to a URL
> that didn't have one before (because the From URL never originally had a
> tag) - thereby changing the call leg identifiers. 
> 
> Robert.
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> > Sent: Friday, July 21, 2000 12:10 AM
> > To: Fairlie-Cuninghame, Robert
> > Cc: 'sip@lists.bell-labs.com'
> > Subject: Re: [SIP] Adding tags across reboots.
> > 
> > 
> > One possibility is to make the From/To tags constant across 
> > reboots and
> > only dependent on the system identity, not its incarnation index. For
> > example, this could be a hash of the user id and a processor 
> > ID and MAC
> > address.
> > 
> > 
> > "Fairlie-Cuninghame, Robert" wrote:
> > > 
> > > I have two queries, the first is about the handling of 
> > received INVITE's
> > > when you have no call state (affecting robustness after 
> > crash); the second
> > > more serious query is about handling BYE, CANCEL, INFO 
> > requests when you
> > > have no call state.
> > > 
> > > In Section 1.5 (point 1)  there is a whole paragraph 
> > devoted to behaviour of
> > > clients that wish to be robust across a crash.
> > > 
> > > Consider the following scenario: UA1 sends INVITE (with no 
> > To or From tags)
> > > to UA2. UA2 adds a To tag in the 200Ok response and this is 
> > used in all
> > > subsequent transactions by both UA's as per RFC.
> > > 
> > > Now UA1 crashes and reboot. UA2 sends a re-INVITE to UA1 
> > (perhaps due to
> > > Session Timer). This re-INVITE will have a From tag but no 
> > To tag and UA1
> > > will treat the re-INIVTE as new call, correct? Thus, it 
> > will then add
> > > _another_ To tag (in what was originally the From field).
> > > 
> > > Should UA2 match this 200Ok response to the existing call ? 
> > No, you can't
> > > change the From tag mid-call. So in this situation you 
> > can't recover from a
> > > crash, right ? So how do you handle this ? [Distinguishing 
> > an INVITE from a
> > > re-INVITE without call state]. I have one suggestion at the 
> > end of this
> > > email.
> > > 
> > > Now, what about handling _non-INVITE_ requests after a 
> > crash. In Section
> > > 6.44 (To), it says that a UAS must place a tag on all final 
> > responses to all
> > > transactions within a call leg. And Section 11 is unclear 
> > on what to do.
> > > 
> > > Let's consider the same scenario described above except 
> > when UA1 receives a
> > > BYE from UA2 after a crash (which is probably much more 
> > likely). This
> > > scenario extends to whenever you receive a BYE, INFO, 
> > CANCEL or similar
> > > post-INVITE request - whenever you would want respond with a 481 Not
> > > exist(ie no call state).
> > > 
> > > UA1 should return a 481 request when it receives the 
> > BYE/INFO/CANCEL but
> > > once again if it was to place a To tag in the 481 response 
> > then UA2 would
> > > not be able to match the response to the request.
> > > 
> > > I think the spec should be clarified in Section11 as to the 
> > behaviour when
> > > BYE/INFO/CANCEL/etc responses are received but no call state exists.
> > > Is the correct behaviour NOT to add a To tag when issuing a 
> > 481? Can anyone
> > > think of some way in which this will affect forking proxies 
> > - I beleive it
> > > should be okay as these requests do not relete to call establisment.
> > > 
> > > One solution that would fix all these problems is to make a From tag
> > > mandatory in INVITE's (even if it is just tag=0) so that a 
> > new tag will not
> > > be added, however this is a fairly heavy burden.
> > > 
> > > Any other ideas?
> > > 
> > > Robert.
> > > 
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> > -- 
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 



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


From sip-admin@lists.bell-labs.com  Thu Jul 20 22:53:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24684
	for ; Thu, 20 Jul 2000 22:53:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CF13D443C6; Thu, 20 Jul 2000 22:53:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id 2D85F4433B
	for ; Thu, 20 Jul 2000 22:53:20 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7J196F>; Thu, 20 Jul 2000 19:53:50 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'sip@lists.bell-labs.com'" 
Date: Thu, 20 Jul 2000 19:53:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Poorman's SIP through firewall.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Yet another SIP firewall proposal:

It provides a way to get past a dumb/non-SIP or RTP aware firewalls where
there are no RTP proxies or firewall control features. This would be the
sort of mechanism used by a PC SIP client on a corporate network to reach
the outside world with no assistance from an unsympathetic network
adminstrator .

It uses RTP over TCP. This will require adding a new "rtp over tcp" profile
for SDP - I have heard other people talking about this for DTMF transport so
I'm sure it will eventually happen. 
[Sure, everyone knows that tcp is not optimal for real-time traffic but it
is used successfully by a lot of existing internet multimedia applications.]


So how does it work ? Simple. It requires no changes to SIP and has needs no
special handling of the firewall case.

Firstly the User-Agents establish a SIP session using TCP to get through the
firewall (a static firewall port map to a SIP proxy would be required for
UA's to call into the firewall). The SIP signalling through a firewall has
always been possible but the tricky part has been punching the media
through.

_Both_ UA's attempt to open a TCP connection to the address list in each of
the m= lines in the SDP body (eg, m=audio 5000 RTP_TCP/AVP 18) - this is
done regardless of whether the m= line is sendonly, recvonly or sendrecv.
Now one or both TCP connections may succeed. The UA's send their media on
the first TCP connection that successfully connects and should receive media
on either the inbound or outbound TCP connection. For robustness the source
port of the TCP connection should come from a different port than the local
port specified in the SDP body (otherwise you could have two TCP sessions
between the same port pair).

In the case of the firewall penetration only one of the two TCP connection
attempts will succeed (the one going from inside to outside the firewall)
but since each connection provides a bidirectional pipe then two way media
flow can be achieved.

Can anyone see any problems with this idea ?

Security issues: 
- interior addresses will be placed in the SDP session (I don't think that's
a major security breach is it?)
- you are forced to accept media connections from unknown IP addresses. I
don't see this as a real problem for internet users - if you want real
security use a proper SIP ALG firewall proxy.

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 Jul 21 00:03:52 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18689
	for ; Fri, 21 Jul 2000 00:03:51 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F3758443B0; Fri, 21 Jul 2000 00:03:32 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31])
	by lists.bell-labs.com (Postfix) with ESMTP id AEAB24433B
	for ; Fri, 21 Jul 2000 00:03:28 -0400 (EDT)
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id AAA22097;
	Fri, 21 Jul 2000 00:01:43 -0400 (EDT)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256923.00161E30 ; Fri, 21 Jul 2000 00:01:35 -0400
X-Lotus-FromDomain: TELCORDIA
From: "Ashutosh Dutta" 
To: sip@lists.bell-labs.com
Message-ID: <85256923.00161D58.00@notes949.cc.telcordia.com>
Date: Fri, 21 Jul 2000 00:00:49 -0400
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] New Internet Draft submission on SIP for Appliance
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com




There was a new draft submitted  on using SIP for Appliances last Friday. Until
it appears in the IETF archive it can be found at the following location.

This draft is "named"  draft-moyer-sip-appliances-framework-00.txt
and has the title, "Framework Draft for Networked Appliances Using the
Session Initiation Protocol"

The text and postscript versions of this draft may be found (respectively at)
ftp://ftp.telcordia.com/pub/world/stanm/ietf/draft-moyer-sip-appliances-framework-00.txt

and
ftp://ftp.telcordia.com/pub/world/stanm/ietf/draft-moyer-sip-appliances-framework-00.ps


(In addition a PDF version is also available at
ftp://ftp.telcordia.com/pub/world/stanm/ietf/draft-moyer-sip-appliances-framework-00.pdf
)


Thanks
Ashutosh




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


From sip-admin@lists.bell-labs.com  Fri Jul 21 00:54: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 ESMTP id AAA08289
	for ; Fri, 21 Jul 2000 00:54:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6E9C944395; Fri, 21 Jul 2000 00:54:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 488254433B
	for ; Fri, 21 Jul 2000 00:54:46 -0400 (EDT)
Received: from dynamicsoft.com (1Cust58.tnt2.freehold.nj.da.uu.net [63.17.114.58])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA27975;
	Fri, 21 Jul 2000 00:56:02 -0400 (EDT)
Message-ID: <3977D869.38F8AFD1@dynamicsoft.com>
Date: Fri, 21 Jul 2000 00:58:17 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Poorman's SIP through firewall.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Fairlie-Cuninghame, Robert" wrote:
> 
> Yet another SIP firewall proposal:
> 
> _Both_ UA's attempt to open a TCP connection to the address list in each of
> the m= lines in the SDP body (eg, m=audio 5000 RTP_TCP/AVP 18) - this is
> done regardless of whether the m= line is sendonly, recvonly or sendrecv.
> Now one or both TCP connections may succeed. The UA's send their media on
> the first TCP connection that successfully connects and should receive media
> on either the inbound or outbound TCP connection. For robustness the source
> port of the TCP connection should come from a different port than the local
> port specified in the SDP body (otherwise you could have two TCP sessions
> between the same port pair).
> 
> In the case of the firewall penetration only one of the two TCP connection
> attempts will succeed (the one going from inside to outside the firewall)
> but since each connection provides a bidirectional pipe then two way media
> flow can be achieved.
> 
> Can anyone see any problems with this idea ?

1. still doesn't work with nat
2. doesn't work if both users are behind firewalls (both TCP connections
will fail)
3. many firewalls won't let tcp out on dynamic ports; only fixed ones
like 80, and then often just from a proxy
4. latency will really suck

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 01:04:54 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12229
	for ; Fri, 21 Jul 2000 01:04:53 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D1F9443C3; Fri, 21 Jul 2000 01:04:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CF41D443B8
	for ; Fri, 21 Jul 2000 01:04:00 -0400 (EDT)
Received: from dynamicsoft.com (1Cust58.tnt2.freehold.nj.da.uu.net [63.17.114.58])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA27992;
	Fri, 21 Jul 2000 01:05:30 -0400 (EDT)
Message-ID: <3977DAA1.AA167FF3@dynamicsoft.com>
Date: Fri, 21 Jul 2000 01:07:45 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shail Bhatnagar 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Shail Bhatnagar wrote:
> 
> Let us say proxy "proxy.domain.com" listening at port 5060 receives
> this request :
> 
> INVITE sip:abc@xyz.com SIP/2.0
> 
> and it introduces a Record-Route header.
> My question is should the Record-Route look like :
> 
> 
> 
> or
> 
> 

Actually, neither. Its:



i.e., you *copy* the request URI into the record-route, and add your own
address into the port, maddr, transport parameters.


> 
> On a related note, what should proxies do with maddr parameter in
> the incoming request-URI ( the request may or may not have a Route).

If the domain in the request URI is your own, and you are using some
kind of location service to translate the address, you do nothing with
it. If, however, you are a local outbound proxy, and you are simply
forwarding to the server listed in the request URI, you will send it to
the server at the maddr.

See:
http://www.cs.columbia.edu/~hgs/sip/faq/cache/62.html


> 
> My third question is about the following statement in section 4.3
> 
> "The host portion of the Request-URI typically agrees with one of
> the host names of the receiving server. If it does not the proxy
> SHOULD proxy the request to the address indicated or return a 404..."
> 
> As per the above statement, if the proxy "proxy.domain.com" at port
> 5060 gets the following request :
> 
> INVITE sip:abc@proxy.domain.com:5055 SIP/2.0
> 
> it would try to lookup user abc instead of forwarding the request
> on the local machine to port 5055. Is it okay to do this ??

Sure. Routing is your own decision. 

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 01:29:45 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28466
	for ; Fri, 21 Jul 2000 01:29:45 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EDCD944395; Fri, 21 Jul 2000 01:29:34 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id AD8FB4433B
	for ; Fri, 21 Jul 2000 01:29:31 -0400 (EDT)
Received: from dynamicsoft.com (1Cust58.tnt2.freehold.nj.da.uu.net [63.17.114.58])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA28048;
	Fri, 21 Jul 2000 01:30:57 -0400 (EDT)
Message-ID: <3977E098.FA84D712@dynamicsoft.com>
Date: Fri, 21 Jul 2000 01:33:12 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dvir Oren 
Cc: SIP 
Subject: Re: [SIP] Local Calls
References: <14711.29860.208804.340373@jodie.lucid>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Dvir Oren wrote:
> 
> I'm asking again because I did not get an
> answer last time.  Perhaps I didn't explain myself
> very clearly.  I realize that this is somewhat
> of an implementation issue, however I was
> hoping for a standardized solution.
> 
> Suppose I have a SIP Telephone that has
> 2 lines.  The SIP Implementation has a
> UAC and a UAS, which both share their
> "call database".
> 
> How do I make a call between line 1 and line 2?
> The UAC will send the INVITE to the UAS
> through loopback.
> 
> The UAS will now go over the "call database"
> to see if this is an INVITE retransmission.

But its not. This would be the first INVITE you have *received*, thus
how can it be a retransmission?

If you have a table of transactions by transaction keys (To, From,
Call-ID, CSeq), you should be sure to have the direction of the request
(sent or received) as part of the key, or use separate transaction
tables even for incoming and outgoing requests. 

If you have a table of calls by Call-ID only, you will run into problems
as you may think this is a re-INVITE for the same call. You really want
the incoming and outgoing messages to be associated with totally
different calls. It can be distinguished as a separate call if, again,
you allow for direction in your lookups. There are many ways to do this;
the easiest is to include your local address as part of the call key.
For incoming requests, the key is callID + from, for outgoing, callID+
to. 



-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 01:34:56 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02176
	for ; Fri, 21 Jul 2000 01:34:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B2D3D443CD; Fri, 21 Jul 2000 01:34:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 51DD7443C2
	for ; Fri, 21 Jul 2000 01:34:14 -0400 (EDT)
Received: from dynamicsoft.com (1Cust58.tnt2.freehold.nj.da.uu.net [63.17.114.58])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA28065;
	Fri, 21 Jul 2000 01:35:41 -0400 (EDT)
Message-ID: <3977E1B4.E0FED8E7@dynamicsoft.com>
Date: Fri, 21 Jul 2000 01:37:56 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dvir Oren 
Cc: SIP 
Subject: Re: [SIP] Display Name
References: <14711.29353.987564.881674@jodie.lucid>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I believe it has to be a quoted string if it contains non-token
characters:

Contact: "< this is a test" 

-Jonathan R.

Dvir Oren wrote:
> 
> This may be a dumb questions, but I was wondering
> when are you supposed to put quotes around
> a display name?  Am I guaranteed to have
> quotes around a name with spaces?  Can I
> discard spaces in a name without quotes?
> 
> How should I treat a Display Name like this:
> From:  This      is
>   My
>      Name <...>
> 
> ?
> Can I treat it as "This is My Name" <...>?
> 
> --
> Dvir Oren               
> Lucid VON Ltd.     
> 9 Saloniki St.,        Tel-Aviv       Israel
> Tel:  +972 3 644 3038  Fax:  +972 3 644 3039
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 01:54:08 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14168
	for ; Fri, 21 Jul 2000 01:54:08 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 93368443D0; Fri, 21 Jul 2000 01:53:55 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 4965D44395
	for ; Fri, 21 Jul 2000 01:53:52 -0400 (EDT)
Received: from dynamicsoft.com (1Cust58.tnt2.freehold.nj.da.uu.net [63.17.114.58])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA28126
	for ; Fri, 21 Jul 2000 01:55:24 -0400 (EDT)
Message-ID: <3977E653.102BACC5@dynamicsoft.com>
Date: Fri, 21 Jul 2000 01:57:39 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] bar bofs
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Folks,

One further thing on the two bar bofs (multiparty conferencing and
subscriptions/notifications/events). If you want to attend, also let me
know when you are available so I can schedule it at a reasonable time.

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 05:00:34 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06956
	for ; Fri, 21 Jul 2000 05:00:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A336B44395; Fri, 21 Jul 2000 05:00:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id D672B4433B
	for ; Fri, 21 Jul 2000 05:00:02 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA09776; Fri, 21 Jul 2000 09:57:44 +0100 (BST)
From: "Jo Hornsby" 
To: "Dvir Oren" , "SIP" 
Subject: RE: [SIP] BYE at the callee through proxies
Date: Fri, 21 Jul 2000 09:57:44 +0100
Message-ID: <001601bff2f1$bc195480$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <14711.29193.815764.324729@jodie.lucid>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> I don't understand to whom a callee should send its
> BYE to.

The Contact address -- this is now mandated in the bis draft.

> Should it do a user lookup on the From 
> SIP URL?

I guess in the absence of a Contact address, this is probably
the best it can do.  (I'm assuming that by "user lookup" you're
talking about the rules in 1.4.2.)

> What happens if there are any proxies
> that need to be informed along the way?

No problem, the Record-Route mechanism works just fine.

> For the caller - this is simple.  It receives
> the Record-Route, which is then translated to
> Route on the ACK, and can be saved for the BYE
> (Though this may be implementation difficult
> since after sending the ACK, it should have removed
> the first Record-Route, though it needs it for the 
> BYE).

I don't understand this.  Basically, the client should
be maintaining some sort of state on the Call-Leg, and
include the Record-Route seen in the 200 (or whatever)
with this state.

The server should do similar (it will see the Record-Route
in the initial INVITE).

> But the callee theoretically doesn't have this
> information.  By the time it receives the ACK,
> there will be no Route information.  It can,
> save the Record-Route information from the
> 200 Success, and then turn it into Route 
> (without reversing the order), though I don't
> see this in the RFC.

See paragraph 4 of section 6.35.2 of the most recent bis
draft.

> It seems like the only thing a callee knows
> is either the From SIP URL (what happens if
> the URL is incorrect, or the hostname there is
> not known at the callee?), in which case it will
> have to do a user lookup to find how to reach the URL,
> and hopefully it will travel through the same procies,
> though not necessarily.  Or it has saved the Contact
> that the caller gave it (if it gave a Contact), in
> which case the BYE will definitely not travel
> through the proxies.

It will if Record-Route was specified, and the callee
appended the Contact header value to the Route header
list, as detailed at the end of 6.35.2.

> Or it can try to use the Record-Route information,
> which will contain the wrong user!

Yes, but that is handled by the paragraph 4 mentioned
above.

HTH,


 - Jo.




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


From sip-admin@lists.bell-labs.com  Fri Jul 21 05:23:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20497
	for ; Fri, 21 Jul 2000 05:23:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 71B27443C4; Fri, 21 Jul 2000 05:23:29 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 62597443C0
	for ; Fri, 21 Jul 2000 05:23:25 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA12253; Fri, 21 Jul 2000 10:21:32 +0100 (BST)
From: "Jo Hornsby" 
To: "Shail Bhatnagar" , 
Subject: RE: [SIP] Record-Route and maddr
Date: Fri, 21 Jul 2000 10:21:32 +0100
Message-ID: <001701bff2f5$0f17cab0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <39778379.931BBCA3@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> Let us say proxy "proxy.domain.com" listening at port 5060 receives
> this request :
> 
> INVITE sip:abc@xyz.com SIP/2.0
> 
> and it introduces a Record-Route header.
> My question is should the Record-Route look like :
> 
> 
> 
> or 
> 
> 

I think the former.

> On a related note, what should proxies do with maddr parameter in
> the incoming request-URI ( the request may or may not have a Route).

Going on Section 1.4.2 (steps 1, 2, 7) in the bis, it should send
it to the IP corresponding to the maddr parameter, and figure the
port based on the paragraph immediately proceeding these steps.

(As a side note: is it really the intention that port numbers in
SRV records should override an _explicitly_ specified port number
in a Request-URI?  This seems a little odd.  For example, say
I wanted to run a test server on an obscure port on some machine
that was running a live server; how would I get a conforming UAC
to talk to the right server?)

> My third question is about the following statement in section 4.3
> 
> "The host portion of the Request-URI typically agrees with one of 
> the host names of the receiving server. If it does not the proxy
> SHOULD proxy the request to the address indicated or return a 404..."
> 
> As per the above statement, if the proxy "proxy.domain.com" at port
> 5060 gets the following request :
> 
> INVITE sip:abc@proxy.domain.com:5055 SIP/2.0
> 
> it would try to lookup user abc instead of forwarding the request
> on the local machine to port 5055. Is it okay to do this ??

Basically, it's okay to do anything. &:)

I would say that's completely fine; it's odd (see my parenthesised
rant above), but if that's what policy dictates...

HTH,


 - Jo.



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


From sip-admin@lists.bell-labs.com  Fri Jul 21 05:48:38 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05125
	for ; Fri, 21 Jul 2000 05:48:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F06A2443C4; Fri, 21 Jul 2000 05:48:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id D3AAE4433B
	for ; Fri, 21 Jul 2000 05:48:12 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA13724; Fri, 21 Jul 2000 10:46:07 +0100 (BST)
From: "Jo Hornsby" 
To: "Jonathan Rosenberg" ,
        "Dvir Oren" 
Cc: "SIP" 
Subject: RE: [SIP] Display Name
Date: Fri, 21 Jul 2000 10:46:06 +0100
Message-ID: <001801bff2f8$7dc3d320$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <3977E1B4.E0FED8E7@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> I believe it has to be a quoted string if it contains non-token
> characters:
> 
> Contact: "< this is a test" 

Is this definitely right?

6.15 says:
    Contact = ( "Contact" | "m" ) ":" 
                 ("*" | (1# (( name-addr | addr-spec )
                 *( ";" contact-params ) )))

       name-addr      = [ display-name ] "<" addr-spec ">"
       addr-spec      = SIP-URL | URI
       display-name   = *token | quoted-string

And given the "implied *LWS" rule in appendix C, doesn't that
make
Contact: Monsieur Muppet 
legal?


 - 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 Jul 21 05:58:23 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10771
	for ; Fri, 21 Jul 2000 05:58:22 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 65AB4443DB; Fri, 21 Jul 2000 05:58:00 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from roma.axis.se (roma.axis.se [193.13.178.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 8863044396
	for ; Fri, 21 Jul 2000 05:57:56 -0400 (EDT)
Received: from klatt.axis.se (klatt.axis.se [193.13.178.133])
	by roma.axis.se (8.9.3/8.9.3) with ESMTP id LAA20348;
	Fri, 21 Jul 2000 11:57:25 +0200 (MEST)
Received: by klatt.axis.se with Internet Mail Service (5.5.2650.21)
	id ; Fri, 21 Jul 2000 11:57:24 +0200
Message-ID: <151F3D2AE9F0D3119E480004ACB8EA37018690A3@cluster01.axis.se>
From: Peter Kjellerstedt 
To: "'Jo Hornsby'" 
Cc: SIP 
Subject: RE: [SIP] Display Name
Date: Fri, 21 Jul 2000 11:56:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

> -----Original Message-----
> From: Jo Hornsby [mailto:jhornsby@ubiquity.net]
> Sent: 21 July 2000 11:46
> To: Jonathan Rosenberg; Dvir Oren
> Cc: SIP
> Subject: RE: [SIP] Display Name
> 
> > I believe it has to be a quoted string if it contains non-token
> > characters:
> > 
> > Contact: "< this is a test" 
> 
> Is this definitely right?

Yes. Note the reference to non-token characters above (in this
case it is the < character, not the spaces).

> 6.15 says:
>     Contact = ( "Contact" | "m" ) ":" 
>                  ("*" | (1# (( name-addr | addr-spec )
>                  *( ";" contact-params ) )))
> 
>        name-addr      = [ display-name ] "<" addr-spec ">"
>        addr-spec      = SIP-URL | URI
>        display-name   = *token | quoted-string
> 
> And given the "implied *LWS" rule in appendix C, doesn't that make
> Contact: Monsieur Muppet  legal?

Yes, it does too. In this case it is tokens separated by LWS.

>  - Jo.

//Peter


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 07:00:40 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13641
	for ; Fri, 21 Jul 2000 07:00:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E8777443DE; Fri, 21 Jul 2000 07:00:24 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 129FF4433B
	for ; Fri, 21 Jul 2000 07:00:18 -0400 (EDT)
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id LAA14391; Fri, 21 Jul 2000 11:58:23 +0100 (BST)
Message-ID: <39782CCE.4BFF8A3E@ubiquity.net>
Date: Fri, 21 Jul 2000 11:58:22 +0100
From: Neil Deason 
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Shail Bhatnagar wrote:
> >
> > Let us say proxy "proxy.domain.com" listening at port 5060 receives
> > this request :
> >
> > INVITE sip:abc@xyz.com SIP/2.0
> >
> > and it introduces a Record-Route header.
> > My question is should the Record-Route look like :
> >
> > 
> >
> > or
> >
> > 
> 
> Actually, neither. Its:
> 
> 

This is exactly the same as the first suggestion?? 

> i.e., you *copy* the request URI into the record-route, and add your own
> address into the port, maddr, transport parameters.

I thought that proxies MUST include the maddr param 
in the URI of the Record-Route header, but MUST NOT
include a transport param. (Section 6.35.1) 

Is a proxy also supposed to write it's port number 
into the Request-URI if it is not 5060? This isn't 
clear to me in the spec but seems necessary for 
clients to know where to send to later on.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 07:52:37 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06004
	for ; Fri, 21 Jul 2000 07:52:37 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4E319443B7; Fri, 21 Jul 2000 07:52:19 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp2.kolumbus.fi (smtp2.kolumbus.fi [193.229.0.37])
	by lists.bell-labs.com (Postfix) with ESMTP id DB1C94433B
	for ; Fri, 21 Jul 2000 07:52:15 -0400 (EDT)
Received: from hpylab (hpylab.rc.hpy.fi [192.126.6.2])
	by smtp2.kolumbus.fi (8.9.0/8.9.0) with SMTP id OAA08420
	for ; Fri, 21 Jul 2000 14:52:14 +0300 (EET DST)
Received: from rc.hpy.fi by hpylab (SMI-8.6/SMI-SVR4)
	id OAA26827; Fri, 21 Jul 2000 14:47:00 +0300
Message-ID: <39783983.2F1FDBFD@rc.hpy.fi>
Date: Fri, 21 Jul 2000 14:52:35 +0300
From: Eero Vaarnas 
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Proxying user names to phone numbers
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


I have a question about proxying invitations to a different user name
(or phone_number@host). At first, what fields should the Proxy Server
modify, and secondly by what field should the User Agent identify the
incoming INVITEs?
  I haven't found any call flow examples in the SIP WG pages or in this
list, and different SIP software and hardware show mixed results. If I
register address user@domain.com to be contacted at
14471447@machine.domain.com, most servers would send the INVITE
something like this:

INVITE sip:14471447@machine.domain.com SIP/2.0
To: "user" 
From: "sender" 
Call-ID: 369f7bcc788173aae3c9fdf0e2035ebe@sender_machine.domain.com
Via: SIP/2.0/UDP sip_proxy.domain.com:5060; branch=1
Via: SIP/2.0/UDP sender_machine.domain.com:5060
CSeq: 5 INVITE
Content-Type: application/sdp
Content-Length: 141


In other words, the request URI is changed, leaving the "To" field
unmodified. Most User Agents understand this INVITE, but some others
return "Not found 404". They work fine, if I create a user with the user
name "14471447" at the proxy also. Then the message looks like this:

INVITE sip:14471447@machine.domain.com SIP/2.0
To: "14471447" 
From: "sender" 
Call-ID: 369f7bcc788173aae3c9fdf0e2035ebe@sender_machine.domain.com
Via: SIP/2.0/UDP sip_proxy.domain.com:5060; branch=1
Via: SIP/2.0/UDP sender_machine.domain.com:5060
CSeq: 5 INVITE
Content-Type: application/sdp
Content-Length: 141


Somehow it seems that they check only that the user name in "To" field
matches. With phone numbers this makes sense, but with arbitrary user
names it seems weird. Shouldn't the idea be that any _address_ can be
mapped to any other, without the need to user names to be "global". 
  According to rfc2543, request URI is the field that identifies the
user in the final endpoint. Am I right that User Agents should answer to
INVITEs with their user name at the request URI, not in the "To" field?

-- 
Eero Vaarnas


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 09:58:09 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13775
	for ; Fri, 21 Jul 2000 09:58:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8856B443B7; Fri, 21 Jul 2000 08:54:04 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 8DBFA4433B
	for ; Fri, 21 Jul 2000 08:54:01 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jul 21 08:52:25 EDT 2000
Received: by lists.bell-labs.com (Postfix)
	id 88A9C4435F; Fri, 21 Jul 2000 08:39:16 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hzsgg01.nl.lucent.com (hzsgg01.nl.lucent.com [135.85.32.33])
	by lists.bell-labs.com (Postfix) with SMTP id 9311E44347
	for ; Fri, 21 Jul 2000 08:39:15 -0400 (EDT)
Received: from lucent.com (hzsgp04.nl.lucent.com) by hzsgg01.nl.lucent.com (4.1/SMI-4.1)
	id AA21718; Fri, 21 Jul 00 14:39:14 +0200
Message-Id: <397844A1.D2D971F9@lucent.com>
Date: Fri, 21 Jul 2000 14:40:01 +0200
From: Paul Sijben 
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: multipart/mixed;
 boundary="------------EB25EB160633357806BE0161"
Subject: [SIP] [Fwd: I-D ACTION:draft-tiphon-background-00.txt]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

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

SIP-experts,

next week TIPHON is expected to approve a work item to desribe how its new
architecture can be implemented using SIP.

The architecture and its background are described in the follwing two IDs:
 draft-tiphon-background-00.txt
 draft-tiphon-architecture-00.txt

I hope TIPHON can have a serious look at the mapping to SIP at its meeting
next week and come up with a list of questions. 

I would appreciate if there would be time to discuss these questions with the
assembled SIP experts in Pittsburgh.

If there is interest and if time permists I would be happy to give a
presentation in TIPHONs current work and their relationship to SIP.

Paul Sijben
-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Message:+31 208702874			
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)
--------------EB25EB160633357806BE0161
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: 
Received: from horh1.emsr.lucent.com (horh1.emsr.lucent.com [135.17.1.40])
	by hzsgp68.nl.lucent.com (8.9.3/8.9.3) with ESMTP id TAA12347
	for ; Wed, 19 Jul 2000 19:55:14 +0200
Received: from hoemail2.firewall.lucent.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr)
	id NAA23085 for ; Wed, 19 Jul 2000 13:51:10 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA13732;
	Wed, 19 Jul 2000 13:51:10 -0400 (EDT)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA13606;
	Wed, 19 Jul 2000 13:51:04 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA14323
	for ietf-123-outbound.03@ietf.org; Wed, 19 Jul 2000 11:35:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA11217
	for ; Wed, 19 Jul 2000 06:34:29 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20907
	for ; Wed, 19 Jul 2000 06:34:30 -0400 (EDT)
Message-Id: <200007191034.GAA20907@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;;@loki.ietf.org@horh1.emsr.lucent.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-tiphon-background-00.txt
Date: Wed, 19 Jul 2000 06:34:30 -0400
Sender: nsyracus@cnri.reston.va.us
X-Mozilla-Status2: 00000000

--NextPart

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


	Title		: TIPHON architecture background
	Author(s)	: S. Cadzow, P. Mart, P. Sijben
	Filename	: draft-tiphon-background-00.txt
	Pages		: 12
	Date		: 18-Jul-00
	
The background and objectives of the new ETSI project Tiphon
architecture are described in this draft. The architecture is shown
to be capable of use by a number of different signalling systems and
session control protocols, including SIP and H.323. The opportunity
exists for the IETF to help with the technology mappings for SIP to
ensure inter-operation with other technologies through the TIPHON
architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-tiphon-background-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-tiphon-background-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-tiphon-background-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:	<20000718135700.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-tiphon-background-00.txt

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

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

--OtherAccess--

--NextPart--


--------------EB25EB160633357806BE0161--



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


From sip-admin@lists.bell-labs.com  Fri Jul 21 11:10:59 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20695
	for ; Fri, 21 Jul 2000 11:10:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6DB3F443C7; Fri, 21 Jul 2000 11:09:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204])
	by lists.bell-labs.com (Postfix) with ESMTP id 68FAB4433B
	for ; Fri, 21 Jul 2000 11:09:02 -0400 (EDT)
Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA00410;
	Fri, 21 Jul 2000 11:08:34 -0400 (EDT)
Message-ID: <39786774.60BE141B@cisco.com>
Date: Fri, 21 Jul 2000 11:08:36 -0400
From: Shail Bhatnagar 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jo Hornsby 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <001701bff2f5$0f17cab0$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jo Hornsby wrote:
> 
> > Let us say proxy "proxy.domain.com" listening at port 5060 receives
> > this request :
> >
> > INVITE sip:abc@xyz.com SIP/2.0
> >
> > and it introduces a Record-Route header.
> > My question is should the Record-Route look like :
> >
> > 
> >
> > or
> >
> > 
> 
> I think the former.
> 
> > On a related note, what should proxies do with maddr parameter in
> > the incoming request-URI ( the request may or may not have a Route).
> 
> Going on Section 1.4.2 (steps 1, 2, 7) in the bis, it should send
> it to the IP corresponding to the maddr parameter, and figure the
> port based on the paragraph immediately proceeding these steps.
> 
> (As a side note: is it really the intention that port numbers in
> SRV records should override an _explicitly_ specified port number
> in a Request-URI?  This seems a little odd.  For example, say
> I wanted to run a test server on an obscure port on some machine
> that was running a live server; how would I get a conforming UAC
> to talk to the right server?)

I thought that if there is an explicit port in the SIP URL, then 
type "A" query should be done, otherwise type "SRV" query.




> 
> > My third question is about the following statement in section 4.3
> >
> > "The host portion of the Request-URI typically agrees with one of
> > the host names of the receiving server. If it does not the proxy
> > SHOULD proxy the request to the address indicated or return a 404..."
> >
> > As per the above statement, if the proxy "proxy.domain.com" at port
> > 5060 gets the following request :
> >
> > INVITE sip:abc@proxy.domain.com:5055 SIP/2.0
> >
> > it would try to lookup user abc instead of forwarding the request
> > on the local machine to port 5055. Is it okay to do this ??
> 
> Basically, it's okay to do anything. &:)
> 
> I would say that's completely fine; it's odd (see my parenthesised
> rant above), but if that's what policy dictates...
> 
> HTH,
> 
>  - Jo.
> 
> _______________________________________________


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 11:41:58 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04028
	for ; Fri, 21 Jul 2000 11:41:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B417944355; Fri, 21 Jul 2000 11:41:37 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from alpha.telecom-co.net (unknown [200.21.27.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 6A11C44337
	for ; Fri, 21 Jul 2000 11:41:31 -0400 (EDT)
Received: from MABOL ([200.21.27.154]) by alpha.telecom-co.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id PH6ANKBD; Fri, 21 Jul 2000 10:40:33 -0500
Message-ID: <001401bff32a$2e98b900$9a1b15c8@mabol.telefonia>
From: "=?iso-8859-1?Q?Mauricio_Bola=F1os_Arturo?=" 
To: 
Date: Fri, 21 Jul 2000 10:41:42 -0500
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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Subject: [SIP] sip call Scheduling service
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

Hi everyone!

If I would like to make a sip call Scheduling service could I make it of the
following form?

The user sends an INVITE request to a proxy server with a SDP body  in which
there is a field "t=" or "r=" with information about the time (hour, minute)
that he wants to make the call. The server catches the request and look that
the message body has the time field ( "t=" or  "r=" or both) and sends this
information to the service logic. Time later when the call desired hour
arrives, the proxy server sends an INVITE request to the destination, and if
he accepts it then the proxy sends an INVITE request or a  message response
( 2xx) to the origin.
Is possible to make it using these SDP fields only??

thanks a lot

Mauricio Bolaños Arturo
ITEC -TELECOM
Bogotá Colombia



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


From sip-admin@lists.bell-labs.com  Fri Jul 21 11:52:05 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08528
	for ; Fri, 21 Jul 2000 11:52:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C8D0F443CE; Fri, 21 Jul 2000 11:51:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67])
	by lists.bell-labs.com (Postfix) with ESMTP id CEE94443CC
	for ; Fri, 21 Jul 2000 11:51:42 -0400 (EDT)
Received: (from smtpd@localhost)
	by ns01.newbridge.com (8.9.2/8.9.2) id LAA09058
	for ; Fri, 21 Jul 2000 11:44:48 -0400 (EDT)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com"
 via SMTP by ns01.newbridge.com, id smtpdBAA0yD3F9; Fri Jul 21 11:44:40 2000
Received: from kong.starvision.com by kanata-mh1.ca.newbridge.com with ESMTP for sip@lists.bell-labs.com; Fri, 21 Jul 2000 11:51:02 -0400
Received: from lion (lion [192.168.208.171])
	by starvision.com (8.8.8+Sun/8.8.8) with SMTP id IAA12484
	for ; Fri, 21 Jul 2000 08:51:36 -0700 (PDT)
Message-Id: <081101bff32a$f731df40$abd0a8c0@starvision.com>
From: "Serban Tatu" 
To: 
Date: Fri, 21 Jul 2000 08:47:24 -0700
Organization: Starvision Multimedia
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.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Subject: [SIP] Re: summary: DTMF and voice-over-packet
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Sorry for picking up this thread again, but after reading the messages for the
last couple of weeks, it seems to me that:

1. There is no unique standard way of marrying DTMF and SIP, and regardless of
which method you pick (RTP or INFO method), you're bound to get in trouble. Is
it worth trying to support both? Any other ones?

2. Some people say that RTP/RFC2833 is the way to go. However, in the SIP Call
Flows Examples draft
(http://search.ietf.org/internet-drafts/draft-ietf-sip-call-flows-01.txt),
section 5.1. shows a DTMF digit carried by an INFO request. What's that thing
doing there?

Are there any devices (gateways or others) that speak SIP and deal with DTMF?
How does a SIP phone send DTMF digits to an IVR or an answering machine?

Any input appreciated, thanks,
Serban

---------------------------------------------
Serban Tatu
Starvision Multimedia
http://www.starvision.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 Jul 21 11:58:18 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11107
	for ; Fri, 21 Jul 2000 11:58:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 19F96443E0; Fri, 21 Jul 2000 11:58:12 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 4673E443C0
	for ; Fri, 21 Jul 2000 11:58:09 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA00320;
	Fri, 21 Jul 2000 11:56:23 -0400 (EDT)
Message-ID: <39787331.5F5AE040@dynamicsoft.com>
Date: Fri, 21 Jul 2000 11:58:41 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eero Vaarnas 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Proxying user names to phone numbers
References: <39783983.2F1FDBFD@rc.hpy.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Eero Vaarnas wrote:
> 
> I have a question about proxying invitations to a different user name
> (or phone_number@host). At first, what fields should the Proxy Server
> modify, 

as always, request URI.

and secondly by what field should the User Agent identify the
> incoming INVITEs?

request URI.

>   I haven't found any call flow examples in the SIP WG pages or in this
> list, and different SIP software and hardware show mixed results. If I
> register address user@domain.com to be contacted at
> 14471447@machine.domain.com, most servers would send the INVITE
> something like this:
> 
> INVITE sip:14471447@machine.domain.com SIP/2.0
> To: "user" 
> From: "sender" 
> Call-ID: 369f7bcc788173aae3c9fdf0e2035ebe@sender_machine.domain.com
> Via: SIP/2.0/UDP sip_proxy.domain.com:5060; branch=1
> Via: SIP/2.0/UDP sender_machine.domain.com:5060
> CSeq: 5 INVITE
> Content-Type: application/sdp
> Content-Length: 141
> 

Thats correct.

> 
> In other words, the request URI is changed, leaving the "To" field
> unmodified. Most User Agents understand this INVITE, but some others
> return "Not found 404". They work fine, if I create a user with the user
> name "14471447" at the proxy also. Then the message looks like this:
> 
> INVITE sip:14471447@machine.domain.com SIP/2.0
> To: "14471447" 
> From: "sender" 
> Call-ID: 369f7bcc788173aae3c9fdf0e2035ebe@sender_machine.domain.com
> Via: SIP/2.0/UDP sip_proxy.domain.com:5060; branch=1
> Via: SIP/2.0/UDP sender_machine.domain.com:5060
> CSeq: 5 INVITE
> Content-Type: application/sdp
> Content-Length: 141
> 

This message would only get sent if the caller knew the called party as
sip:14471447@domain.com, and explicitly addressed them as such.

> 
> Somehow it seems that they check only that the user name in "To" field
> matches.

That is wrong. It is the request URI, for both phone numbers and names.

> With phone numbers this makes sense, but with arbitrary user
> names it seems weird. Shouldn't the idea be that any _address_ can be
> mapped to any other, without the need to user names to be "global".
>   According to rfc2543, request URI is the field that identifies the
> user in the final endpoint. Am I right that User Agents should answer to
> INVITEs with their user name at the request URI, not in the "To" field?

Absolutely correct.

We'll clarify and I'll add this to the FAQ.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 12:04:54 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14082
	for ; Fri, 21 Jul 2000 12:04:53 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8C914443EA; Fri, 21 Jul 2000 12:04:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D8ED144337
	for ; Fri, 21 Jul 2000 12:04:42 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA00437;
	Fri, 21 Jul 2000 12:06:14 -0400 (EDT)
Message-ID: <39787580.6C0EED25@dynamicsoft.com>
Date: Fri, 21 Jul 2000 12:08:32 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Serban Tatu 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Re: summary: DTMF and voice-over-packet
References: <081101bff32a$f731df40$abd0a8c0@starvision.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Serban Tatu wrote:
> 
> Sorry for picking up this thread again, but after reading the messages for the
> last couple of weeks, it seems to me that:
> 
> 1. There is no unique standard way of marrying DTMF and SIP, and regardless of
> which method you pick (RTP or INFO method), you're bound to get in trouble. Is
> it worth trying to support both? Any other ones?

Our goal is to try and come to conclusion on this. The discussion seemed
to lean towards using rfc2833; objections were getting down to minor
issues which were related to current server implementations. You claim
both can get you into trouble. Can you elaborate on that?

> 
> 2. Some people say that RTP/RFC2833 is the way to go. However, in the SIP Call
> Flows Examples draft
> (http://search.ietf.org/internet-drafts/draft-ietf-sip-call-flows-01.txt),
> section 5.1. shows a DTMF digit carried by an INFO request. What's that thing
> doing there?

Oops. That needs to go. The call flows draft should only be referencing
standard approaches for message flows.


> 
> Are there any devices (gateways or others) that speak SIP and deal with DTMF?
> How does a SIP phone send DTMF digits to an IVR or an answering machine?

Right now, the same way the telephone network does it. Encoded in the
audio stream.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 12:09:10 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15696
	for ; Fri, 21 Jul 2000 12:09:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BACDA443EF; Fri, 21 Jul 2000 12:08:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 16DD8443E8
	for ; Fri, 21 Jul 2000 12:08:08 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA00501;
	Fri, 21 Jul 2000 12:09:17 -0400 (EDT)
Message-ID: <39787637.D0B14F7A@dynamicsoft.com>
Date: Fri, 21 Jul 2000 12:11:35 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mauricio =?iso-8859-1?Q?Bola=F1os?= Arturo 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] sip call Scheduling service
References: <001401bff32a$2e98b900$9a1b15c8@mabol.telefonia>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

This is overloading the meaning of these fields within SDP.

If you want to schedule a server to call you at some time, I suggest you
enter the data in a web page and have the application server use that
data to call you at the appropriate time. SIP is not meant to be an
event scheduling protocol.

-Jonathan R.

Mauricio Bolaños Arturo wrote:
> 
> Hi everyone!
> 
> If I would like to make a sip call Scheduling service could I make it of the
> following form?
> 
> The user sends an INVITE request to a proxy server with a SDP body  in which
> there is a field "t=" or "r=" with information about the time (hour, minute)
> that he wants to make the call. The server catches the request and look that
> the message body has the time field ( "t=" or  "r=" or both) and sends this
> information to the service logic. Time later when the call desired hour
> arrives, the proxy server sends an INVITE request to the destination, and if
> he accepts it then the proxy sends an INVITE request or a  message response
> ( 2xx) to the origin.
> Is possible to make it using these SDP fields only??
> 
> thanks a lot
> 
> Mauricio Bolaños Arturo
> ITEC -TELECOM
> Bogotá Colombia
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 12:12:19 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16845
	for ; Fri, 21 Jul 2000 12:12:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E2015443F8; Fri, 21 Jul 2000 12:09:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67])
	by lists.bell-labs.com (Postfix) with ESMTP id 1FCBB443E8
	for ; Fri, 21 Jul 2000 12:09:04 -0400 (EDT)
Received: (from smtpd@localhost)
	by ns01.newbridge.com (8.9.2/8.9.2) id MAA11082;
	Fri, 21 Jul 2000 12:02:04 -0400 (EDT)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com"
 via SMTP by ns01.newbridge.com, id smtpdAAALBXLd_; Fri Jul 21 12:02:01 2000
Received: from kong.starvision.com by kanata-mh1.ca.newbridge.com with ESMTP; Fri, 21 Jul 2000 12:08:26 -0400
Received: from lion (lion [192.168.208.171])
	by starvision.com (8.8.8+Sun/8.8.8) with SMTP id JAA13164;
	Fri, 21 Jul 2000 09:09:00 -0700 (PDT)
Message-Id: <001301bff32d$655f5e50$abd0a8c0@starvision.com>
From: "Serban Tatu" 
To: "Jonathan Rosenberg" 
Cc: 
References: <081101bff32a$f731df40$abd0a8c0@starvision.com> <39787580.6C0EED25@dynamicsoft.com>
Subject: Re: [SIP] Re: summary: DTMF and voice-over-packet
Date: Fri, 21 Jul 2000 09:04:48 -0700
Organization: Starvision Multimedia
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.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: Jonathan Rosenberg 
To: Serban Tatu 
Cc: 
Sent: Friday, July 21, 2000 9:08 AM
Subject: Re: [SIP] Re: summary: DTMF and voice-over-packet


>
>
> Serban Tatu wrote:
> >
> > 1. There is no unique standard way of marrying DTMF and SIP, and regardless
of
> > which method you pick (RTP or INFO method), you're bound to get in trouble.
Is
> > it worth trying to support both? Any other ones?
>
> Our goal is to try and come to conclusion on this. The discussion seemed
> to lean towards using rfc2833; objections were getting down to minor
> issues which were related to current server implementations. You claim
> both can get you into trouble. Can you elaborate on that?

I guess what I meant is that if you pick one way and implement it, then there
will be some equipment that implements it the other way, and your box will not
interoperate with someone else's box. That's why I asked whether it's worth
implementing both...

Thanks,
Serban



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


From sip-admin@lists.bell-labs.com  Fri Jul 21 12:18:42 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19307
	for ; Fri, 21 Jul 2000 12:18:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3047E44407; Fri, 21 Jul 2000 12:12:53 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 7A36944404
	for ; Fri, 21 Jul 2000 12:12:49 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA00549;
	Fri, 21 Jul 2000 12:14:09 -0400 (EDT)
Message-ID: <3978775A.BC475B21@dynamicsoft.com>
Date: Fri, 21 Jul 2000 12:16:26 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Neil Deason 
Cc: Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com> <39782CCE.4BFF8A3E@ubiquity.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Neil Deason wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > Shail Bhatnagar wrote:
> > >
> > > Let us say proxy "proxy.domain.com" listening at port 5060 receives
> > > this request :
> > >
> > > INVITE sip:abc@xyz.com SIP/2.0
> > >
> > > and it introduces a Record-Route header.
> > > My question is should the Record-Route look like :
> > >
> > > 
> > >
> > > or
> > >
> > > 
> >
> > Actually, neither. Its:
> >
> > 
> 
> This is exactly the same as the first suggestion??

Wow. Talk about caffeine deprivation. Sorry about that.

> 
> > i.e., you *copy* the request URI into the record-route, and add your own
> > address into the port, maddr, transport parameters.
> 
> I thought that proxies MUST include the maddr param
> in the URI of the Record-Route header, but MUST NOT
> include a transport param. (Section 6.35.1)

Forgot about that one as well. Thats a result of the recent discussions
on UDP in one side, TCP on the other. Thanks.

> 
> Is a proxy also supposed to write it's port number
> into the Request-URI if it is not 5060? This isn't
> clear to me in the spec but seems necessary for
> clients to know where to send to later on.

If you put an IP address into the maddr parameter, yes, the port number
will need to be there if its not 5060. If you put a domain name, you
will not need it if you wish to rely on SRV records. If you are relying
on A records, again, you'll need it there. Record-routing with domain
names that point to SRV records can be both good and bad. If may cause
subsequent requests to go to a different server. Good for failover, bad
if you don't have state replication mechanisms in the back end between
servers.


Shail writes:
> > (As a side note: is it really the intention that port numbers in
> > SRV records should override an _explicitly_ specified port number
> > in a Request-URI?  This seems a little odd.  For example, say
> > I wanted to run a test server on an obscure port on some machine
> > that was running a live server; how would I get a conforming UAC
> > to talk to the right server?)
> 
> I thought that if there is an explicit port in the SIP URL, then 
> type "A" query should be done, otherwise type "SRV" query.

Correct.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 12:22:25 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20676
	for ; Fri, 21 Jul 2000 12:22:24 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 57BB74441E; Fri, 21 Jul 2000 12:18:57 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1029D44418
	for ; Fri, 21 Jul 2000 12:18:54 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA00625;
	Fri, 21 Jul 2000 12:20:21 -0400 (EDT)
Message-ID: <397878CF.F9DBC321@dynamicsoft.com>
Date: Fri, 21 Jul 2000 12:22:39 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Serban Tatu 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Re: summary: DTMF and voice-over-packet
References: <081101bff32a$f731df40$abd0a8c0@starvision.com> <39787580.6C0EED25@dynamicsoft.com> <001301bff32d$655f5e50$abd0a8c0@starvision.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Serban Tatu wrote:
> 
> > Our goal is to try and come to conclusion on this. The discussion seemed
> > to lean towards using rfc2833; objections were getting down to minor
> > issues which were related to current server implementations. You claim
> > both can get you into trouble. Can you elaborate on that?
> 
> I guess what I meant is that if you pick one way and implement it, then there
> will be some equipment that implements it the other way, and your box will not
> interoperate with someone else's box. That's why I asked whether it's worth
> implementing both...

Then half of the implementations are implementing proprietary protocols.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 12:30:49 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24077
	for ; Fri, 21 Jul 2000 12:30:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9436D44403; Fri, 21 Jul 2000 12:25:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from godzilla.ipdialog.com (mail.ipdialog.com [208.238.222.66])
	by lists.bell-labs.com (Postfix) with ESMTP id D447E4437F
	for ; Fri, 21 Jul 2000 12:25:44 -0400 (EDT)
Received: from ipdialog.com (IDENT:hch@repoman.ipdialog.com [208.238.222.70])
	by godzilla.ipdialog.com (8.9.3/8.8.7) with ESMTP id JAA18931;
	Fri, 21 Jul 2000 09:25:25 -0700
Message-ID: <39787974.99AC13E3@ipdialog.com>
Date: Fri, 21 Jul 2000 09:25:24 -0700
From: Howard Hart 
Organization: ipDialog, Inc.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: "Fairlie-Cuninghame, Robert" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Poorman's SIP through firewall.
References:  <3977D869.38F8AFD1@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Or you could just park yourself on the standard RealAudio TCP/UDP ports. You'd be
amazed at how many sites have this particular hole in place due pressure from the
user population or executive suite, plus most Firewall vendors support it as an
option out of the box. TCP port 7070 (or just use 80) and incoming/outgoing UDP
ports 6970-7170.

Howard Hart
ipDialog, Inc.

Jonathan Rosenberg wrote:

> "Fairlie-Cuninghame, Robert" wrote:
> >
> > Yet another SIP firewall proposal:
> >
> > _Both_ UA's attempt to open a TCP connection to the address list in each of
> > the m= lines in the SDP body (eg, m=audio 5000 RTP_TCP/AVP 18) - this is
> > done regardless of whether the m= line is sendonly, recvonly or sendrecv.
> > Now one or both TCP connections may succeed. The UA's send their media on
> > the first TCP connection that successfully connects and should receive media
> > on either the inbound or outbound TCP connection. For robustness the source
> > port of the TCP connection should come from a different port than the local
> > port specified in the SDP body (otherwise you could have two TCP sessions
> > between the same port pair).
> >
> > In the case of the firewall penetration only one of the two TCP connection
> > attempts will succeed (the one going from inside to outside the firewall)
> > but since each connection provides a bidirectional pipe then two way media
> > flow can be achieved.
> >
> > Can anyone see any problems with this idea ?
>
> 1. still doesn't work with nat
> 2. doesn't work if both users are behind firewalls (both TCP connections
> will fail)
> 3. many firewalls won't let tcp out on dynamic ports; only fixed ones
> like 80, and then often just from a proxy
> 4. latency will really suck
>
> -Jonathan R.
> --
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip



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


From sip-admin@lists.bell-labs.com  Fri Jul 21 12: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 ESMTP id MAA25746
	for ; Fri, 21 Jul 2000 12:35:10 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 304B54440E; Fri, 21 Jul 2000 12:31:22 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204])
	by lists.bell-labs.com (Postfix) with ESMTP id E597A443EA
	for ; Fri, 21 Jul 2000 12:00:57 -0400 (EDT)
Received: from cisco.com (bounty.cisco.com [161.44.3.204])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA04805;
	Fri, 21 Jul 2000 11:59:49 -0400 (EDT)
Message-ID: <39787375.673B6A12@cisco.com>
Date: Fri, 21 Jul 2000 11:59:49 -0400
From: Bryan Byerly 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: wtm@research.att.com, kkrama@research.att.com, E.Miller@Cablelabs.com,
        G.Russell@Cablelabs.com, Burcak_Beser@3com.com,
        Michael_Mannette@3com.com, Kurt_Steinbrenner@3com.com, oran@cisco.com,
        fandreas@cisco.com, jpickens@com21.com, pla1waney@gi.com,
        jfellows@gi.com, drevans@securecable.com, keith@netspeak.com
Cc: byerly@cisco.com, sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] State: header host should be "hostport"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi guys,

We've come across a small bug in the draft-dcsgroup-sip-state-01.txt
while implementing the State: header.

When multiple proxies run on one server (each listening on a separate
port), the current BNF for the State: header is insufficient.  "host"
should be changed to "hostport".

The BNF in draft-dcsgroup-sip-state-01.txt paragraph 2, section 4.1,
State Header Syntax should read:

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [4].


        State           = "State" ":" 1#(hostport ";" state-token
                                *(";" state-token))
        state-token     =  token ["=" (*token | quoted-string)]

If no port is specified, then 5060 should be assumed.

Please update the draft to reflect this change.

Thanks for your help!
Bryan

Bryan J. Byerly
byerly@cisco.com





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


From sip-admin@lists.bell-labs.com  Fri Jul 21 12:40:47 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27998
	for ; Fri, 21 Jul 2000 12:40:46 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 58CFE4437F; Fri, 21 Jul 2000 12:40:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 94EF644337
	for ; Fri, 21 Jul 2000 12:40:01 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id RAA24995; Fri, 21 Jul 2000 17:37:55 +0100 (BST)
From: "Jo Hornsby" 
To: "Jonathan Rosenberg" ,
        "Neil Deason" 
Cc: "Shail Bhatnagar" , 
Subject: RE: [SIP] Record-Route and maddr
Date: Fri, 21 Jul 2000 17:37:54 +0100
Message-ID: <000701bff332$04f01320$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: <3978775A.BC475B21@dynamicsoft.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> > > (As a side note: is it really the intention that port numbers in
> > > SRV records should override an _explicitly_ specified port number
> > > in a Request-URI?  This seems a little odd.  For example, say
> > > I wanted to run a test server on an obscure port on some machine
> > > that was running a live server; how would I get a conforming UAC
> > > to talk to the right server?)
> > 
> > I thought that if there is an explicit port in the SIP URL, then 
> > type "A" query should be done, otherwise type "SRV" query.
> 
> Correct.

Okay, I think I finally get it. &:)

> If you put an IP address into the maddr parameter, yes, the port
> number will need to be there if its not 5060. If you put a domain
> name, you will not need it if you wish to rely on SRV records. If
> you are relying on A records, again, you'll need it there.
> Record-routing with domain names that point to SRV records can be
> both good and bad. If may cause subsequent requests to go to a
> different server. Good for failover, bad if you don't have
> state replication mechanisms in the back end between servers.

Is it possible to rely on SRV _at all_ with Record-Route, though,
since the maddr parameter is a MUST?

As far as I can tell from 1.4.2, the maddr is either going to be
an IP or a host name; if it's the latter, then clients perform
an A (or AAAA, or whatever) lookup...

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 Jul 21 12:45:01 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00111
	for ; Fri, 21 Jul 2000 12:45:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EF386443FC; Fri, 21 Jul 2000 12:40:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 41DF044337
	for ; Fri, 21 Jul 2000 12:40:42 -0400 (EDT)
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id RAA25110; Fri, 21 Jul 2000 17:38:44 +0100 (BST)
Message-ID: <39787C95.481C3BDD@ubiquity.net>
Date: Fri, 21 Jul 2000 17:38:45 +0100
From: Neil Deason 
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com> <39782CCE.4BFF8A3E@ubiquity.net> <3978775A.BC475B21@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Neil Deason wrote:
> >
> > Jonathan Rosenberg wrote:
> > >
> > > Shail Bhatnagar wrote:
> > > >
> > > > Let us say proxy "proxy.domain.com" listening at port 5060 receives
> > > > this request :
> > > >
> > > > INVITE sip:abc@xyz.com SIP/2.0
> > > >
> > > > and it introduces a Record-Route header.
> > > > My question is should the Record-Route look like :
> > > >
> > > > 
> > > >
> > > > or
> > > >
> > > > 
> > >
> > > Actually, neither. Its:
> > >
> > > 
> >
> > This is exactly the same as the first suggestion??
> 
> Wow. Talk about caffeine deprivation. Sorry about that.
> 
> >
> > > i.e., you *copy* the request URI into the record-route, and add your own
> > > address into the port, maddr, transport parameters.
> >
> > I thought that proxies MUST include the maddr param
> > in the URI of the Record-Route header, but MUST NOT
> > include a transport param. (Section 6.35.1)
> 
> Forgot about that one as well. Thats a result of the recent discussions
> on UDP in one side, TCP on the other. Thanks.
> 
> >
> > Is a proxy also supposed to write it's port number
> > into the Request-URI if it is not 5060? This isn't
> > clear to me in the spec but seems necessary for
> > clients to know where to send to later on.
> 
> If you put an IP address into the maddr parameter, yes, the port number
> will need to be there if its not 5060. If you put a domain name, you
> will not need it if you wish to rely on SRV records. If you are relying
> on A records, again, you'll need it there. Record-routing with domain
> names that point to SRV records can be both good and bad. If may cause
> subsequent requests to go to a different server. Good for failover, bad
> if you don't have state replication mechanisms in the back end between
> servers.

What about on reverse request paths where components other 
than the maddr param are taken from the originating name-addr 
value (i.e. Contact header or From header if there is no 
Contact). In this case isn't any port info placed in the 
Request-URI by a proxy wanting to be on the route lost.

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 Jul 21 13:16:49 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15276
	for ; Fri, 21 Jul 2000 13:16:48 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6683F443E0; Fri, 21 Jul 2000 13:16:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sd_exchange.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 5DCE944337
	for ; Fri, 21 Jul 2000 13:16:13 -0400 (EDT)
Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T6TL4GL>; Fri, 21 Jul 2000 10:15:50 -0700
Message-ID: <613A6A6A3F09D3118F5C00508B2C24FEAD8BF1@sd_exchange.nuera.com>
From: "Fox, Mike" 
To: Michael Thomas 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] How to stop a Lawnmower Man attack?
Date: Fri, 21 Jul 2000 10:15:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Oops I need correct one sentence...
>> I would like to be clear in that I'm not trying to suggest 
>> that SIP does [ NOT ] support administrative control. 

>    I don't see how the protocol itself can help. I can
>    see pretty simple call gapping measures at proxies,
>    etc, help though but those don't require any new
>    protocol mechanisms. Also: a UAS can always insist
>    that the initial INVITE come through a trusted 
>    proxy rather than directly from the UAC. Assuming
>    that proxies are more trustworthy because they at
>    least have some admin behind them, you could limit
>    the zombie attack as above.

In other words a Gate Keeper. This is my conclusion too, but so far there is
no GK element proscribed for SIP, why not? Others must have come to a
different conclusion. The nature of the SIP/SDP will allow many flavors of
attack. This is not the protocol's problem, but the issue does need to be
addressed. I have not seen much public discussion in the way of threat
analysis with regard to these issues from the the SIP comunity. I hope
somewhere (perhaps ETSI/TIPHON WG 8) someone will give these issues deeper
consideration.

Best regards,
Mike


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 13:36: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 ESMTP id NAA00138
	for ; Fri, 21 Jul 2000 13:36:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E4677443F4; Fri, 21 Jul 2000 13:36:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204])
	by lists.bell-labs.com (Postfix) with ESMTP id 4D477443DE
	for ; Fri, 21 Jul 2000 13:36:33 -0400 (EDT)
Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA11941;
	Fri, 21 Jul 2000 13:36:13 -0400 (EDT)
Message-ID: <39788A0F.A49BACE0@cisco.com>
Date: Fri, 21 Jul 2000 13:36:15 -0400
From: Shail Bhatnagar 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
 

> >
> > On a related note, what should proxies do with maddr parameter in
> > the incoming request-URI ( the request may or may not have a Route).
> 
> If the domain in the request URI is your own, and you are using some
> kind of location service to translate the address, you do nothing with
> it. If, however, you are a local outbound proxy, and you are simply
> forwarding to the server listed in the request URI, you will send it to
> the server at the maddr.

I think this will not work with Record-Route,since the host portion
of the SIPURL would be entirely different from the maddr parameter
of the Request-URI ( actually I think a proxy will see its address
in the maddr parameter of the incoming Request-URI, but the host
portion of the SIP URL could be anything.)

Comments ??



> 
> See:
> http://www.cs.columbia.edu/~hgs/sip/faq/cache/62.html
> 

From the bis version of the spec :

"The transport, maddr and ttl parameters MUST NOT be used in the From/
To headers fields and the Request-URI, they are ignored if present."

This needs to be changed ??


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


From sip-admin@lists.bell-labs.com  Fri Jul 21 14:29:51 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09785
	for ; Fri, 21 Jul 2000 14:29:50 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E48A1443E0; Fri, 21 Jul 2000 14:29:34 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 73EAF44337
	for ; Fri, 21 Jul 2000 14:29:31 -0400 (EDT)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA16240;
	Fri, 21 Jul 2000 11:29:44 -0700 (PDT)
Received: from buckthorn-nt (dhcp-171-69-93-65.cisco.com [171.69.93.65])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAB18312;
	Fri, 21 Jul 2000 11:29:30 -0700 (PDT)
Message-Id: <4.2.0.58.20000721112600.00d98790@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 21 Jul 2000 11:27:56 -0700
To: "Fox, Mike" 
From: Rohan Mahy 
Subject: RE: [SIP] How to stop a Lawnmower Man attack?
Cc: Michael Thomas , sip@lists.bell-labs.com
In-Reply-To: <613A6A6A3F09D3118F5C00508B2C24FEAD8BF1@sd_exchange.nuera.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Mike,

SIP Proxy Servers correspond to the Gatekeeper function in H.323.  They can 
both provide AAA and perform centralized routing.

thanks,
-rohan


At 10:15 AM 7/21/00 , Fox, Mike wrote:
>Oops I need correct one sentence...
> >> I would like to be clear in that I'm not trying to suggest
> >> that SIP does [ NOT ] support administrative control.
>
> >    I don't see how the protocol itself can help. I can
> >    see pretty simple call gapping measures at proxies,
> >    etc, help though but those don't require any new
> >    protocol mechanisms. Also: a UAS can always insist
> >    that the initial INVITE come through a trusted
> >    proxy rather than directly from the UAC. Assuming
> >    that proxies are more trustworthy because they at
> >    least have some admin behind them, you could limit
> >    the zombie attack as above.
>
>In other words a Gate Keeper. This is my conclusion too, but so far there is
>no GK element proscribed for SIP, why not? Others must have come to a
>different conclusion. The nature of the SIP/SDP will allow many flavors of
>attack. This is not the protocol's problem, but the issue does need to be
>addressed. I have not seen much public discussion in the way of threat
>analysis with regard to these issues from the the SIP comunity. I hope
>somewhere (perhaps ETSI/TIPHON WG 8) someone will give these issues deeper
>consideration.
>
>Best regards,
>Mike
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/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 Jul 21 14:47:21 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25667
	for ; Fri, 21 Jul 2000 14:47:20 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C21B044408; Fri, 21 Jul 2000 14:46:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by lists.bell-labs.com (Postfix) with ESMTP id EA134443FB
	for ; Fri, 21 Jul 2000 14:46:32 -0400 (EDT)
Received: from buckthorn-nt (dhcp-171-69-93-65.cisco.com [171.69.93.65]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA18475 for ; Fri, 21 Jul 2000 11:46:32 -0700 (PDT)
Message-Id: <4.2.0.58.20000721113819.00d92a10@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 21 Jul 2000 11:44:58 -0700
To: sip@lists.bell-labs.com
From: Rohan Mahy 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Session header
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,

The Session header was defined originally in the 183 draft.  Now that the 
183 has expired (?), the 183 response has moved into the bis draft, but the 
Session header has not. Can we still move the Session header into the bis 
draft?

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 Jul 21 15:14:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24891
	for ; Fri, 21 Jul 2000 15:14:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 90D6644409; Fri, 21 Jul 2000 15:14:28 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 22F6544355
	for ; Fri, 21 Jul 2000 15:14:25 -0400 (EDT)
Received: from voicecore.com (user-38lc71c.dialup.mindspring.com [209.86.28.44])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id PAA28664;
	Fri, 21 Jul 2000 15:14:03 -0400 (EDT)
Message-ID: <3978CBFB.D1006614@voicecore.com>
Date: Fri, 21 Jul 2000 15:17:31 -0700
From: Samir Chatterjee 
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Mauricio =?iso-8859-1?Q?Bola=F1os?= Arturo 
Cc: "sip@lists.bell-labs.com" 
Subject: Re: [SIP] sip call Scheduling service
References: <001401bff32a$2e98b900$9a1b15c8@mabol.telefonia>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

Doing it your way means that the proxy server will have to maintain unnecessary
state about this schedule event. While you can create a stateful server but
scalability will soon hit you. The necessary timing event can either be
preprogrammed in your end-point or by off-loading it to some app server which
can later initiate the call. Also, the "t=" and "r=" field have different
interpretations which become non-standard.

Dr. Samir Chatterjee
VoiceCore Technologies Inc &
Georgia State University

Mauricio Bolaños Arturo wrote:

> Hi everyone!
>
> If I would like to make a sip call Scheduling service could I make it of the
> following form?
>
> The user sends an INVITE request to a proxy server with a SDP body  in which
> there is a field "t=" or "r=" with information about the time (hour, minute)
> that he wants to make the call. The server catches the request and look that
> the message body has the time field ( "t=" or  "r=" or both) and sends this
> information to the service logic. Time later when the call desired hour
> arrives, the proxy server sends an INVITE request to the destination, and if
> he accepts it then the proxy sends an INVITE request or a  message response
> ( 2xx) to the origin.
> Is possible to make it using these SDP fields only??
>
> thanks a lot
>
> Mauricio Bolaños Arturo
> ITEC -TELECOM
> Bogotá Colombia
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Jul 21 15:42:10 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19648
	for ; Fri, 21 Jul 2000 15:42:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E0D1844355; Fri, 21 Jul 2000 15:42:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148])
	by lists.bell-labs.com (Postfix) with ESMTP id EE55844337
	for ; Fri, 21 Jul 2000 15:42:00 -0400 (EDT)
Received: from voicecore.com (user-38lc71c.dialup.mindspring.com [209.86.28.44])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA29872
	for ; Fri, 21 Jul 2000 15:41:59 -0400 (EDT)
Message-ID: <3978D287.91ACA7F9@voicecore.com>
Date: Fri, 21 Jul 2000 15:45:27 -0700
From: Samir Chatterjee 
X-Mailer: Mozilla 4.72 [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] SIP & QOS
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Can someone point me to any document, RFCs or web site that discusses
integration of QOS techniques (for actual media transport) with SIP
signaling? I am implying once connection has been set up, how RSVP,
DiffServ tagging or anything else is being interfaced with the audio
transport from an end-point?
Thanks
Samir


Dr. Samir Chatterjee
Chairman & CEO
VoiceCore Technologies Inc.&
Georgia State University




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


From sip-admin@lists.bell-labs.com  Fri Jul 21 15:47:36 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24748
	for ; Fri, 21 Jul 2000 15:47:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8074A44421; Fri, 21 Jul 2000 15:46:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by lists.bell-labs.com (Postfix) with ESMTP id 492D244414
	for ; Fri, 21 Jul 2000 15:46:46 -0400 (EDT)
Received: from buckthorn-nt (dhcp-171-69-93-65.cisco.com [171.69.93.65]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA04884 for ; Fri, 21 Jul 2000 12:46:45 -0700 (PDT)
Message-Id: <4.2.0.58.20000721112514.00cec3c0@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 21 Jul 2000 12:45:11 -0700
To: sip@lists.bell-labs.com
From: Rohan Mahy 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] question on draft-manyfolks
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,

I have some quick clarifying questions on the semantics of the 
direction-tag and confirmation-tag in draft-manyfolks.

 >      qos-attribute    = "a=qos:" strength-tag SP direction-tag
 >                                [SP confirmation-tag]
 >      strength-tag     = ("mandatory" | "optional" | "success" |
 >                                "failure")
 >      direction-tag    = ("send" | "recv" | "sendrecv")
 >      confirmation-tag = "confirm"

Consider an INVITE from A to B with "a=qos:mandatory sendrecv confirm" in 
the SDP.  B replies with a 18x with  "a=qos:mandatory sendrecv confirm".

Because of A's request for qos, B can send an RSVP PATH and get back a 
RESV.  At this point, B knows that bandwidth is reserved from B to A.  B 
needs to send it's COMET right away.  Obviously it can't wait to see if 
bidirectional qos is established because a would wait for B, and B would 
wait for A.

Since B only knows that QoS was established from B to A, does it send 
"a=qos:success recv" in its COMET?  Example packets after the first call 
flow would help here considerably.

Also, presumably A could send a COMET early if it got positive indication 
of bidirectional qos [both a RESV (send direction) and a RESVCONF from B 
(recv direction)].  Is this allowed?

thanks,
-rohan


Relevant section from manyfolks:
 >   When the "Confirm" attribute is present in both the SDP sent by the
 >   session originator to the participant (e.g. in the SIP INVITE
 >   message), and in the SDP sent by the recipient back to the
 >   originator (e.g. in a SIP response message), the session originator
 >   would wait for the COMET message with the success/failure
 >   notification before responding with a COMET message, and responds
 >   instead with a CANCEL if a mandatory precondition is not met, or if
 >   a sufficient combination of optional preconditions are not met.  The
 >   recipient does not wait for the COMET message from the originator
 >   before sending its COMET message.







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


From sip-admin@lists.bell-labs.com  Fri Jul 21 15:52:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00413
	for ; Fri, 21 Jul 2000 15:52:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 27FFE44425; Fri, 21 Jul 2000 15:51:27 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id D098244408
	for ; Fri, 21 Jul 2000 15:51:23 -0400 (EDT)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA09001;
	Fri, 21 Jul 2000 12:51:38 -0700 (PDT)
Received: from buckthorn-nt (dhcp-171-69-93-65.cisco.com [171.69.93.65])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAB19610;
	Fri, 21 Jul 2000 12:51:21 -0700 (PDT)
Message-Id: <4.2.0.58.20000721124904.00d8da00@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 21 Jul 2000 12:49:46 -0700
To: Samir Chatterjee 
From: Rohan Mahy 
Subject: Re: [SIP] SIP & QOS
Cc: "sip@lists.bell-labs.com" 
In-Reply-To: <3978D287.91ACA7F9@voicecore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

http://www.softarmor.com/sipwg/drafts/draft-manyfolks-sip-resource-01.txt

enjoy,
-rohan

At 03:45 PM 7/21/00 , Samir Chatterjee wrote:
>Can someone point me to any document, RFCs or web site that discusses
>integration of QOS techniques (for actual media transport) with SIP
>signaling? I am implying once connection has been set up, how RSVP,
>DiffServ tagging or anything else is being interfaced with the audio
>transport from an end-point?
>Thanks
>Samir
>
>
>Dr. Samir Chatterjee
>Chairman & CEO
>VoiceCore Technologies Inc.&
>Georgia State University
>
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/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 Jul 21 15:53:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02069
	for ; Fri, 21 Jul 2000 15:53:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3436E4442A; Fri, 21 Jul 2000 15:52:33 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from polaris.shore.net (polaris.shore.net [207.244.124.105])
	by lists.bell-labs.com (Postfix) with ESMTP id 00CD344429
	for ; Fri, 21 Jul 2000 15:52:28 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by polaris.shore.net with esmtp (Exim)
	for sip@lists.bell-labs.com
	id 13FiqS-0002GC-00; Fri, 21 Jul 2000 15:52:28 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id PAA16326
	for ; Fri, 21 Jul 2000 15:45:55 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000721154828.00da0e40@hither.rfdsoftware.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Jul 2000 15:53:10 -0400
To: sip@lists.bell-labs.com
From: "Dialout.net (David Yon)" 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Quake-over-SIP?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

	Is there spec/docs for how the Internet multi-player Quake support uses 
SIP?  Anyone know where I can find it?  I heard about this at VON and have 
come up empty in my web searching.

	I'm particularly interesting to see if they are using TCP-based transport 
(for the media, not SIP itself) and how they solved some of the impedance 
mismatches between SDP and TCP-based transports.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net



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


From sip-admin@lists.bell-labs.com  Fri Jul 21 16:20:50 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26655
	for ; Fri, 21 Jul 2000 16:20:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 35E7E44414; Fri, 21 Jul 2000 16:20:16 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id 3452644337
	for ; Fri, 21 Jul 2000 16:20:13 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0FY200801DT4FF@firewall.mcit.com> for sip@lists.bell-labs.com; Fri,
 21 Jul 2000 20:19:52 +0000 (GMT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FY200669DT4EM@firewall.mcit.com>; Fri,
 21 Jul 2000 20:19:52 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 id <0FY200M01DT3K5@dgismtp02.wcomnet.com>; Fri,
 21 Jul 2000 20:19:52 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0FY200M01DT3K2@dgismtp02.wcomnet.com>;
 Fri, 21 Jul 2000 20:19:51 +0000 (GMT)
Received: from C25776A ([166.35.227.169])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with SMTP id <0FY200L4IDSNR0@dgismtp02.wcomnet.com>; Fri,
 21 Jul 2000 20:19:36 +0000 (GMT)
Date: Fri, 21 Jul 2000 15:19:34 -0500
From: Henry Sinnreich 
Subject: RE: [SIP] SIP & QOS
In-reply-to: <3978D287.91ACA7F9@voicecore.com>
To: Samir Chatterjee , sip@lists.bell-labs.com
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

http://search.ietf.org/internet-drafts/draft-sinnreich-aaa-inter
domain-sip-qos-osp-00.txt

http://search.ietf.org/internet-drafts/draft-sinnreich-interdoma
in-sip-qos-osp-01.txt

Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>Samir Chatterjee
>Sent: Friday, July 21, 2000 5:45 PM
>To: sip@lists.bell-labs.com
>Subject: [SIP] SIP & QOS
>
>
>Can someone point me to any document, RFCs or web site
>that discusses
>integration of QOS techniques (for actual media
>transport) with SIP
>signaling? I am implying once connection has been set
>up, how RSVP,
>DiffServ tagging or anything else is being interfaced
>with the audio
>transport from an end-point?
>Thanks
>Samir
>
>
>Dr. Samir Chatterjee
>Chairman & CEO
>VoiceCore Technologies Inc.&
>Georgia State University
>
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/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 Jul 21 19:58:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03745
	for ; Fri, 21 Jul 2000 19:58:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D61EB443EA; Fri, 21 Jul 2000 19:57:29 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204])
	by lists.bell-labs.com (Postfix) with ESMTP id BE3E344337
	for ; Fri, 21 Jul 2000 19:57:25 -0400 (EDT)
Received: from cisco.com (bounty.cisco.com [161.44.3.204])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id TAA07238;
	Fri, 21 Jul 2000 19:57:06 -0400 (EDT)
Message-ID: <3978E351.D340A837@cisco.com>
Date: Fri, 21 Jul 2000 19:57:05 -0400
From: Bryan Byerly 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: byerly@cisco.com, ddaiker@cisco.com, shbhatna@cisco.com
Content-Type: multipart/mixed;
 boundary="------------B87B8409FCA81AB874CDFAB1"
Subject: [SIP] SIP Record-Route/Route Hiding I-D
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

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

Hi guys,

Attached is an I-D on SIP Record-Route/Route Hiding.

The goal of the I-D is to allow usage of features requiring the SIP
Record-Route/Route headers while preventing leakage of layer 5 routing
information through these headers to untrusted SIP proxies and user
agents.

We would appreciate your thoughts/criticisms/corrections on this I-D and
encourage discussion on adding it into the RFC2543bis I-D.

Thanks!

Bryan

Bryan J. Byerly
Cisco Systems
byerly@cisco.com



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

Internet Engineering Task Force                         Bryan J. Byerly
Internet Draft                                             David Daiker
draft-byerly-sip-hide-route-00.txt                 Shailandra Bhatnagar
July, 2000                                                Cisco Systems
Expires: January, 2001
                                                      




                    SIP Record-Route/Route Hiding

Status of this Memo

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

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

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

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

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

Abstract

  This document describes a proposed extension to SIP.
  This document proposes a mechansim to encrypt/hide Record-Route and
  Route entries in or to support confidentiality of SIP proxy
  routing information.  The functionality of the Record-Route and
  Route headers are preserved.

  The introduction of this extension allows a set of
  trusted SIP proxies to cooperatively hide the route that
  SIP PDUs transit from untrusted proxies and user agents.






Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 1

Internet Draft      SIP Record-Route/Route Hiding              July 2000

1 Introduction

  Some ISPs value the ability to limit topology knowledge that
  untrusted users can glean from network traffic transiting
  the ISP's borders.

  One example of this is configuration of ISP routers to not respond
  to traceroute ICMP queries.  Another example is usage of the
  SIP Via header hiding.

  Although the SIP RFC (RFC2543) specifies Via hiding/encryption
  as a mechanism to prevent leakage of layer 5 routing information
  from Via headers, it does not address routing information leaked
  through Record-Route and Route headers.

  This draft proposes a SIP extension which preserves the
  functionality of Route and Record-Route headers but prevents
  leakage of routing information through those headers.

  The main difference between Via hiding and Record-Route/Route
  hiding is the directionality in which hiding needs to occur.
  Via header hiding/encryption is needed only unidirectionally
  (from caller to called party).  Record-Route/Route header
  hiding is needed bi-directionally.

  The approach proposed for Record-Route/Route header hiding
  is the same approach taken for Via header hiding:
  Each proxy protects its previous hop.





















Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 2

Internet Draft      SIP Record-Route/Route Hiding              July 2000

2 Mechanics of Record-Route/Route header hiding

2.1 Message flow of Record-Route/Route without Record-Route/Route hiding

    The diagram below illustrates the normal message flow when proxies
    P1, P2, and P3 add themselves to the Record-Route header.

    UAC      P1       P2       P3       UAS
    |        |        |        |        |
    |--REQ-->|        |        |        |
    |        |        |        |        |
    |        |--REQ-->|        |        |
    |        |  Record-Route: P1        |
    |        |        |        |        |
    |        |        |--REQ-->|        |
    |        |        |  Record-Route: P2, P1
    |        |        |        |        |
    |        |        |        |--REQ-->|
    |        |        |        |  Record-Route: P3, P2, P1
    |        |        |        |        |
    |        |        |        |<-RSP---|
    |        |        |        |  Record-Route: P3, P2, P1
    |        |        |        |  Contact: UAS
    |        |        |        |        |
    |        |        |<-RSP---|        |
    |        |        |  Record-Route: P3, P2, P1
    |        |        |  Contact: UAS
    |        |        |        |        |
    |        |<-RSP---|        |        |
    |        |  Record-Route: P3, P2, P1
    |        |  Contact: UAS   |        |
    |        |        |        |        |
    |<-RSP---|        |        |        |
    | Record-Route: P3, P2, P1 |        |
    | Contact: UAS    |        |        |
    |        |        |        |        |
    |--REQ-->|        |        |        |
    |  Route: P2, P3, UAS      |        |
    |        |        |        |        |
    |        |--REQ-->|        |        |
    |        |  Route: P3, UAS |        |
    |        |        |        |        |
    |        |        |--REQ-->|        |
    |        |        |  Route: UAS     |
    |        |        |        |        |
    |        |        |        |--REQ-->|
    |        |        |        |        |


Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 3

Internet Draft      SIP Record-Route/Route Hiding              July 2000

2.2 Algorithm for Record-Route header hiding:

    The approach used to encrypt Record-Route and Route headers is
    the same approach used to encrypt Via headers:
    Each proxy protects its previous hop.

    In the following logic "right" and "left" refer to the order
    of entries in a catenated header. For example, in:

    Record-Route: , , 

     is to the left of .
     is to the right of .

2.2.1 Request handling logic:

      Here's the proxy logic to implement on a request PDU:

      /* Record-Route header logic */
      if (this proxy is introducing himself into Record-Route header) {
          if (a Record-Route entry already exists) {
              Using your secret key, encrypt and replace the
                left-most entry.
          }
          Add your FQDN to the beginning of the Record-Route header
      }

      /* Route header logic */
      if (topmost Route entry is marked "hidden") {
          Remove the topmost entry of the Route header.

          Using your secret key, decrypt this entry and
            route this PDU to it.
      }


2.2.2 Record-Route response logic:

      Here's the proxy logic to implement on a response PDU:
      
      /* Record-Route header logic */
      if (your plain-text FQDN is present in the Record-Route header) {
          if (a Record-Route entry exists to left) {
              Using your secret key, encrypt and replace the
                left entry.
          }

          if ((a Record-Route entry exists to right) &&
              (the entry is marked "hidden")) {
              Using your secret key, decrypt and replace the
                right entry.
          }
      }

Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 4

Internet Draft      SIP Record-Route/Route Hiding              July 2000

2.3 Reusing Hide header

    The Hide: [hop/route] header usage is extended to apply to
    Record-Route and Route headers (as well as Via headers).

    The Hide: [hop/route] header usage is extended to be
    bi-directional.  (i.e. The Hide header may be present in
    requests and/or responses).

    See [RFC2543, Section 6.23 Hide] for more information on Hide
    header.

    A client or proxy requesting "Hide: hop/route" can only rely on
    keeping the path private if it sends the request to a trusted proxy.

    Hidden Record-Route and Route headers reuse the Via header "hidden"
    option as described in [RFC2543, Section 6.44].

2.4 Design tradeoffs/considerations

    There is an advantage gained by encrypting the Record-Route/Route
    information instead of simply hiding the information in proxy
    control blocks.  Storing the route information in a proxy would
    require the proxy to maintain long-duration state.  Pushing the
    route state to the endpoints allows the proxy to remain stateless.

    The disadvantage to encryption is that it requires more processing
    in SIP proxies and therefore impacts signalling latency.
    This results in increased call setup times.

    When a proxy encrypts headers such as Via, State, and
    Record-Route/Route, the proxy is encrypting information
    for its own future use.  In such cases, use of a private key
    suffices.  (i.e. No key exchange operations are needed).










Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 5

Internet Draft      SIP Record-Route/Route Hiding              July 2000

2.5 Message flow using encrypted Record-Route/Route

    The diagram below illustrates the message flow when proxies
    P1, P2, and P3 add themselves to the Record-Route header using
    encrypted Record-Route/Route headers.

    In the message flow below, K1 represents proxy 1's secret key,
    K2 represents proxy 2's secret key, and K3 represents proxy 3's
    secret key.  The E(X, Kn) syntax indicates the encrypted form
    of X using key n.  REQ indicates a SIP request message (such
    as INVITE or ACK).  RSP indicates a SIP response message
    (such as 200).

    UAC      P1       P2       P3       UAS
    |        |        |        |        |
    |--REQ-->|        |        |        |
    |        |        |        |        |
    |        |--REQ-->|        |        |
    |        |  Record-Route: P1        |
    |        |  Hide: hop      |        |
    |        |        |        |        |
    |        |        |--REQ-->|        |
    |        |        |  Record-Route: P2, E(P1,K2)
    |        |        |  Hide: hop      |
    |        |        |        |        |
    |        |        |        |--REQ-->|
    |        |        |        |  Record-Route: P3, E(P2,K3), E(P1,K2)
    |        |        |        |  Hide: hop
    |        |        |        |        |
    |        |        |        |<-RSP---|
    |        |        |        |  Record-Route: P3, E(P2,K3), E(P1,K2)
    |        |        |        |  Contact: UAS
    |        |        |        |        |
    |        |        |<-RSP---|        |
    |        |        |  Record-Route: P3, P2, E(P1,K2)
    |        |        |  Contact: UAS   |
    |        |        |  Hide: hop      |
    |        |        |        |        |
    |        |<-RSP---|        |        |
    |        |  Record-Route: E(P3,K2), P2, P1
    |        |  Contact: UAS   |        |
    |        |  Hide: hop      |        |
    |        |        |        |        |
    |<-RSP---|        |        |        |
    | Record-Route: E(P3,K2), E(P2,K1), P1
    | Contact: UAS    |        |        |
    | Hide: hop       |        |        |
    |        |        |        |        |
    |--REQ-->|        |        |        |
    |  Route: E(P2,K1), E(P3,K2), UAS   |
    |        |        |        |        |
    |        |--REQ-->|        |        |
    |        |  Route: E(P3,K2), UAS    |
    |        |        |        |        |
    |        |        |--REQ-->|        |
    |        |        |  Route: UAS     |
    |        |        |        |        |
    |        |        |        |--REQ-->|
    |        |        |        |        |

Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 6

Internet Draft      SIP Record-Route/Route Hiding              July 2000

3 Security Considerations

  Security issues are the primary topic of this RFC.

  This document proposes an extension to SIP to prevent leakage
  of layer 5 routing information to untrusted proxies and user
  agents through Record-Route and Route headers. 

  The use of Record-Route/Route and Via header hiding is discouraged
  unless path privacy is truly needed; Hide fields impose extra
  processing costs and restrictions for proxies.































Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 6

Internet Draft      SIP Record-Route/Route Hiding              July 2000

4 Further Examples

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

4.1 Standard INVITE/200/ACK sequence using Record-Route/Route and
    Via header hiding

    In this example, proxies P1, P2, and P3 are all configured
    to request Hide: hop.

UAC        P1          P2          P3          UAS
|          |           |           |           | 
|--[1]INV->|           |           |           |
|          |           |           |           |
|          |--[2]INV-->|           |           |
|          |  Record-Route: P1     |           |
|          |  Hide: hop            |           |
|          |           |           |           |
|          |           |--[3]INV-->|           |
|          |           |  Record-Route: P2, E(P1,K2)
|          |           |  Hide: hop            |
|          |           |           |           |
|          |           |           |--[4]INV-->|
|          |           |           |  Record-Route: P3, E(P2,K3),
|          |           |           |           |    E(P1,K2)
|          |           |           |  Hide: hop
|          |           |           |           |
|          |           |           |<-[5]200---|
|          |           |           |  Record-Route: P3, E(P2,K3),
|          |           |           |           |    E(P1,K2)
|          |           |           |  Contact: UAS
|          |           |           |           |
|          |           |<-[6]200---|           |
|          |           |  Record-Route: P3, P2, E(P1,K2)
|          |           |  Contact: UAS         |
|          |           |  Hide: hop            |
|          |           |           |           |
|          |<-[7]200---|           |           |
|          |  Record-Route: E(P3,K2), P2, P1   |
|          |  Contact: UAS         |           |
|          |  Hide: hop            |           |
|          |           |           |           |
|<-[8]200--|           |           |           |
| Record-Route: E(P3,K2), E(P2,K1), P1         |
| Contact: UAS         |           |           |
| Hide: hop            |           |           |
|          |           |           |           |
|--[9]ACK->|           |           |           |
|  Route: E(P2,K1), E(P3,K2), UAS  |           |
|          |           |           |           |
|          |--[10]ACK->|           |           |
|          |  Route: E(P3,K2), UAS |           |
|          |           |           |           |
|          |           |--[11]ACK->|           |
|          |           |  Route: UAS           |
|          |           |           |           |
|          |           |           |--[12]ACK->|
|          |           |           |           |
|          |           |           |           |

Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 7

Internet Draft      SIP Record-Route/Route Hiding              July 2000

     [1] SIP UAC to SIP proxy server 1:

          INVITE sip:bob@p1.isp.com SIP/2.0
          Via: SIP/2.0/UDP alice-pc.isp.com
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

     [2] SIP proxy server 1 to SIP proxy server 2:

          INVITE sip:bob@p2.isp.com SIP/2.0
          Via: SIP/2.0/UDP p1.isp.com
          Via: E(SIP/2.0/UDP alice-pc.isp.com, K1);hidden
          Record-Route: 
          Hide: hop
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

     [3] SIP proxy server 2 to SIP proxy server 3:

          INVITE sip:bob@p3.isp.com SIP/2.0
          Via: SIP/2.0/UDP p2.isp.com
          Via: E(SIP/2.0/UDP p1.isp.com, K2);hidden
          Via: E(SIP/2.0/UDP alice-pc.isp.com, K1);hidden
          Record-Route: ,
                        ;hidden
          Hide: hop
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 8

Internet Draft      SIP Record-Route/Route Hiding              July 2000

     [4] SIP proxy server 3 to UAS:

          INVITE sip:bob@bob-pc.isp.com SIP/2.0
          Via: SIP/2.0/UDP p3.isp.com
          Via: E(SIP/2.0/UDP p2.isp.com, K3);hidden
          Via: E(SIP/2.0/UDP p1.isp.com, K2);hidden
          Via: E(SIP/2.0/UDP alice-pc.isp.com, K1);hidden
          Record-Route: ,
                        ;hidden,
                        ;hidden
          Hide: hop
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

     [5] UAS to SIP proxy server 3:

          SIP/2.0 200 OK
          Via: SIP/2.0/UDP p3.isp.com
          Via: E(SIP/2.0/UDP p2.isp.com, K3);hidden
          Via: E(SIP/2.0/UDP p1.isp.com, K2);hiddden
          Via: E(SIP/2.0/UDP alice-pc.isp.com, K1);hidden
          Record-Route: ,
                        ;hidden,
                        ;hidden
          Contact: bob-pc.isp.com
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

     [6] SIP proxy server 3 to SIP proxy server 2:

          SIP/2.0 200 OK
          Via: SIP/2.0/UDP p2.isp.com
          Via: E(SIP/2.0/UDP p1.isp.com, K2);hidden
          Via: E(SIP/2.0/UDP alice-pc.isp.com, K1);hidden
          Record-Route: ,
                        ,
                        ;hidden
          Contact: bob-pc.isp.com
          Hide: hop
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt    Page 9

Internet Draft      SIP Record-Route/Route Hiding              July 2000

     [7] SIP proxy server 2 to SIP proxy server 1:

          SIP/2.0 200 OK
          Via: SIP/2.0/UDP p1.isp.com
          Via: E(SIP/2.0/UDP alice-pc.isp.com, K1);hidden
          Record-Route: ;hidden,
                        ,
                        
          Contact: bob-pc.isp.com
          Hide: hop
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

     [8] SIP proxy server 1 to UAC

          SIP/2.0 200 OK
          Via: SIP/2.0/UDP alice-pc.isp.com
          Record-Route: ;hidden,
                        ;hidden,
                        
          Contact: bob-pc.isp.com
          Hide: hop
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

     [9] SIP UAC to SIP proxy server 1:

          ACK sip:p1.isp.com SIP/2.0
          Via: SIP/2.0/UDP alice-pc.isp.com
          Route: ;hidden,
                 ;hidden,
                 
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp






Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt   Page 10

Internet Draft      SIP Record-Route/Route Hiding              July 2000

     [10] SIP proxy server 1 to SIP proxy server 2:

          ACK sip:p2.isp.com SIP/2.0
          Via: SIP/2.0/UDP p1.isp.com
          Via: E(SIP/2.0/UDP alice-pc.isp.com, K1);hidden
          Route: ;hidden,
                 
          Hide: hop
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

     [11] SIP proxy server 2 to SIP proxy server 3:

          ACK sip:p3.isp.com SIP/2.0
          Via: SIP/2.0/UDP p2.isp.com
          Via: E(SIP/2.0/UDP p1.isp.com, K2);hidden
          Via: E(SIP/2.0/UDP alice-pc.isp.com, K1);hidden
          Route: 
          Hide: hop
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp

     [12] SIP proxy server 3 to UAS:

          ACK sip:bob-pc.isp.com SIP/2.0
          Via: SIP/2.0/UDP p3.isp.com
          Via: E(SIP/2.0/UDP p2.isp.com, K3);hidden
          Via: E(SIP/2.0/UDP p1.isp.com, K2);hidden
          Via: E(SIP/2.0/UDP alice-pc.isp.com, K1);hidden
          Hide: hop
          From: sip:alice@isp.com
          To: sip:bob@isp.com
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Content-Type: application/sdp







Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt   Page 11

Internet Draft      SIP Record-Route/Route Hiding              July 2000

     Outstanding issues/questions:
     1) We are re-using the Hide: header to imply that
        Via headers AND Record-Route/Route headers should be
        hidden by proxies.
        Is this ok?  Alternatively, another header (Hide-Route:)
        could be used.

        This draft redefines the Hide: header to mean that both
        Via headers AND Record-Route/Route headers should be hidden.

     2) Can/should we use the State: header to store entries for
        Record-Route/Route?
        NOTES:
        - The State header itself leaks routing information
          unless each proxy encrypts all previously added
          State headers.

     3) Can we do simple hiding of Record-Route/Route entries?
        NOTES:
        -  This would appear to cause a proxy to maintain
           long-term route state.

6 Acknowledgements

   We would like to thank David Williams, Nilesh Trivedi,
   and JC Ferguson of Cisco Systems for their insights, inputs,
   and comments.

7 References

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

[SIP-ID] Handley, Schulzrinne, Schooler, Rosenberg.
         "SIP: Session Initiation Protocol",
         draft-ietf-sip-rfc2543bis-00.ps, July 13, 2000.

[SIP-STATE] Marshall, W. et al. "SIP Extensions for supporting
            Distributed Call State", draft-dcsgroup-sip-state-01.txt,
            March 2000.

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












Byerly/Daiker/Bhatnagar     draft-byerly-sip-hide-route-00.txt   Page 12

Internet Draft      SIP Record-Route/Route Hiding              July 2000



Authors' Addresses

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

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

   Shailandra Bhatnagar
   Cisco Systems
   7025 Kit Creek Road
   P.O. Box 14987
   Research Triangle Park, NC 27709
   USA
   Email: shbhatna@cisco.com


--------------B87B8409FCA81AB874CDFAB1--



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


From sip-admin@lists.bell-labs.com  Fri Jul 21 22:23:17 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20484
	for ; Fri, 21 Jul 2000 22:23:17 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C5947443F1; Fri, 21 Jul 2000 22:22:58 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from prserv.net (out2.prserv.net [32.97.166.32])
	by lists.bell-labs.com (Postfix) with ESMTP id CD13444337
	for ; Fri, 21 Jul 2000 22:22:52 -0400 (EDT)
Received: from cs.columbia.edu ([32.101.160.226])
          by prserv.net (out2) with SMTP
          id <2000072202215122901v2qqne>; Sat, 22 Jul 2000 02:21:52 +0000
Message-ID: <397904B0.53506BEF@cs.columbia.edu>
Date: Fri, 21 Jul 2000 22:19:28 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Mauricio =?iso-8859-1?Q?Bola=F1os?= Arturo ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] sip call Scheduling service
References: <001401bff32a$2e98b900$9a1b15c8@mabol.telefonia> <39787637.D0B14F7A@dynamicsoft.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

I suppose you could use "Retry-After" if somebody automatically calls
back, but that's really stretching it. Overloading the SDP media session
timing for session-level things is not a good idea.

Adding an automatic mechanism to follow a link at a particular time
would be a useful feature for calendar software, e.g., to automatically
announce a multicast meeting.


Jonathan Rosenberg wrote:
> 
> This is overloading the meaning of these fields within SDP.
> 
> If you want to schedule a server to call you at some time, I suggest you
> enter the data in a web page and have the application server use that
> data to call you at the appropriate time. SIP is not meant to be an
> event scheduling protocol.
> 
> -Jonathan R.
> 
> Mauricio Bolaños Arturo wrote:
> >
> > Hi everyone!
> >
> > If I would like to make a sip call Scheduling service could I make it of the
> > following form?
> >
> > The user sends an INVITE request to a proxy server with a SDP body  in which
> > there is a field "t=" or "r=" with information about the time (hour, minute)
> > that he wants to make the call. The server catches the request and look that
> > the message body has the time field ( "t=" or  "r=" or both) and sends this
> > information to the service logic. Time later when the call desired hour
> > arrives, the proxy server sends an INVITE request to the destination, and if
> > he accepts it then the proxy sends an INVITE request or a  message response
> > ( 2xx) to the origin.
> > Is possible to make it using these SDP fields only??
> >
> > thanks a lot
> >
> > Mauricio Bolaños Arturo
> > ITEC -TELECOM
> > Bogotá Colombia
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> --
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip




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


From sip-admin@lists.bell-labs.com  Sun Jul 23 00:38:39 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04041
	for ; Sun, 23 Jul 2000 00:38:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5B15D44343; Sun, 23 Jul 2000 00:37:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 119CE44336
	for ; Sun, 23 Jul 2000 00:37:46 -0400 (EDT)
Received: from dynamicsoft.com (1Cust192.tnt1.freehold.nj.da.uu.net [63.17.113.192])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA05132;
	Sun, 23 Jul 2000 00:39:11 -0400 (EDT)
Message-ID: <397A7781.5AFDA4CF@dynamicsoft.com>
Date: Sun, 23 Jul 2000 00:41:37 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Dialout.net (David Yon)" 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Quake-over-SIP?
References: <4.3.2.7.2.20000721154828.00da0e40@hither.rfdsoftware.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Dialout.net (David Yon)" wrote:
> 
>         Is there spec/docs for how the Internet multi-player Quake support uses
> SIP?  Anyone know where I can find it?  I heard about this at VON and have
> come up empty in my web searching.

I asked the folks who worked on it to submit an I-D for the meeting, but
I haven't seen anything. It would be very nice to see that.

> 
>         I'm particularly interesting to see if they are using TCP-based transport
> (for the media, not SIP itself) and how they solved some of the impedance
> mismatches between SDP and TCP-based transports.

SDP is not a transport, so comparing it to TCP is apples/oranges.
Apparently you can simply start quake with command line parameters that
point to a server, game name, etc. It is my understanding that they
simply passed these parameters in SDP. Something like:

m=application 3726 tcp quake
a=fmtp:quake 

would be my guess about how it was accomplished.

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


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 01:28:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20844
	for ; Sun, 23 Jul 2000 01:28:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3EAAE4434A; Sun, 23 Jul 2000 01:28:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 03E7C44336
	for ; Sun, 23 Jul 2000 01:27:57 -0400 (EDT)
Received: from dynamicsoft.com (1Cust192.tnt1.freehold.nj.da.uu.net [63.17.113.192])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA05183;
	Sun, 23 Jul 2000 01:29:13 -0400 (EDT)
Message-ID: <397A833B.F226C26D@dynamicsoft.com>
Date: Sun, 23 Jul 2000 01:31:39 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fox, Mike" 
Cc: Michael Thomas , sip@lists.bell-labs.com
Subject: Re: [SIP] How to stop a Lawnmower Man attack?
References: <613A6A6A3F09D3118F5C00508B2C24FEAD8BF1@sd_exchange.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



"Fox, Mike" wrote:
> 
> Oops I need correct one sentence...
> >> I would like to be clear in that I'm not trying to suggest
> >> that SIP does [ NOT ] support administrative control.
> 
> >    I don't see how the protocol itself can help. I can
> >    see pretty simple call gapping measures at proxies,
> >    etc, help though but those don't require any new
> >    protocol mechanisms. Also: a UAS can always insist
> >    that the initial INVITE come through a trusted
> >    proxy rather than directly from the UAC. Assuming
> >    that proxies are more trustworthy because they at
> >    least have some admin behind them, you could limit
> >    the zombie attack as above.
> 
> In other words a Gate Keeper. This is my conclusion too, but so far there is
> no GK element proscribed for SIP, why not?

There is no need to define an additional element, or standardize
interfaces or protocols for it. This role can be played by a proxy. I
suspect, in fact, there are many ingenious ways you can build logic into
a proxy to prevent such attacks - call setup rate thresholds, etc.
Leaving these to the imaginations of implementors as a source of vendor
differentiation, rather than standardizing them in a protocol document,
seems a better way to go. 

That said, I do agree it would be nice to have a document that describes
the threats in a SIP system, with some discussions on protocol
mechanisms that might exist to alleviate them. This would be an
informational document. It was my hope that the security task force
(which has been a bit quiet as of late) would generate such a 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: (732) 741-7244
http://www.dynamicsoft.com


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 02:19:35 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21198
	for ; Sun, 23 Jul 2000 02:19:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 44DA944344; Sun, 23 Jul 2000 02:19:27 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id EA99D44336
	for ; Sun, 23 Jul 2000 02:19:23 -0400 (EDT)
Received: from dynamicsoft.com (1Cust192.tnt1.freehold.nj.da.uu.net [63.17.113.192])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA05274;
	Sun, 23 Jul 2000 02:20:44 -0400 (EDT)
Message-ID: <397A8F4E.8C504403@dynamicsoft.com>
Date: Sun, 23 Jul 2000 02:23:10 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shail Bhatnagar 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com> <39788A0F.A49BACE0@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Shail Bhatnagar wrote:
> 
> Jonathan Rosenberg wrote:
> 
> 
> > >
> > > On a related note, what should proxies do with maddr parameter in
> > > the incoming request-URI ( the request may or may not have a Route).
> >
> > If the domain in the request URI is your own, and you are using some
> > kind of location service to translate the address, you do nothing with
> > it. If, however, you are a local outbound proxy, and you are simply
> > forwarding to the server listed in the request URI, you will send it to
> > the server at the maddr.
> 
> I think this will not work with Record-Route,since the host portion
> of the SIPURL would be entirely different from the maddr parameter
> of the Request-URI ( actually I think a proxy will see its address
> in the maddr parameter of the incoming Request-URI, but the host
> portion of the SIP URL could be anything.)

This rule above is only in the case where there is no Route header. If
there is a Route header, you always send the request to the IP address
in the maddr of the Route, if present, otherwise, the IP address
resulting from looking up the domain portion of the URI in the Route.

So, it works fine.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 02:24:27 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23384
	for ; Sun, 23 Jul 2000 02:24:24 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6396344352; Sun, 23 Jul 2000 02:23:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1C5984434E
	for ; Sun, 23 Jul 2000 02:23:46 -0400 (EDT)
Received: from dynamicsoft.com (1Cust192.tnt1.freehold.nj.da.uu.net [63.17.113.192])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA05278;
	Sun, 23 Jul 2000 02:21:24 -0400 (EDT)
Message-ID: <397A8F76.BE9DB8AD@dynamicsoft.com>
Date: Sun, 23 Jul 2000 02:23:50 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Neil Deason 
Cc: Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com> <39782CCE.4BFF8A3E@ubiquity.net> <3978775A.BC475B21@dynamicsoft.com> <39787C95.481C3BDD@ubiquity.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Neil Deason wrote:
> 
> >
> > If you put an IP address into the maddr parameter, yes, the port number
> > will need to be there if its not 5060. If you put a domain name, you
> > will not need it if you wish to rely on SRV records. If you are relying
> > on A records, again, you'll need it there. Record-routing with domain
> > names that point to SRV records can be both good and bad. If may cause
> > subsequent requests to go to a different server. Good for failover, bad
> > if you don't have state replication mechanisms in the back end between
> > servers.
> 
> What about on reverse request paths where components other
> than the maddr param are taken from the originating name-addr
> value (i.e. Contact header or From header if there is no
> Contact). In this case isn't any port info placed in the
> Request-URI by a proxy wanting to be on the route lost.

I can't seem to parse this response. Can you rephrase?

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 02:26:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24178
	for ; Sun, 23 Jul 2000 02:26:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 244834436A; Sun, 23 Jul 2000 02:24:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 9C1F444350
	for ; Sun, 23 Jul 2000 02:24:39 -0400 (EDT)
Received: from dynamicsoft.com (1Cust192.tnt1.freehold.nj.da.uu.net [63.17.113.192])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA05286;
	Sun, 23 Jul 2000 02:22:18 -0400 (EDT)
Message-ID: <397A8FAC.EE482A4E@dynamicsoft.com>
Date: Sun, 23 Jul 2000 02:24:44 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jo Hornsby 
Cc: Neil Deason , Shail Bhatnagar ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <000701bff332$04f01320$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jo Hornsby wrote:
> 
> > If you put an IP address into the maddr parameter, yes, the port
> > number will need to be there if its not 5060. If you put a domain
> > name, you will not need it if you wish to rely on SRV records. If
> > you are relying on A records, again, you'll need it there.
> > Record-routing with domain names that point to SRV records can be
> > both good and bad. If may cause subsequent requests to go to a
> > different server. Good for failover, bad if you don't have
> > state replication mechanisms in the back end between servers.
> 
> Is it possible to rely on SRV _at all_ with Record-Route, though,
> since the maddr parameter is a MUST?

Yes, as I said, since the maddr itself can contain a domain name.

> 
> As far as I can tell from 1.4.2, the maddr is either going to be
> an IP or a host name; if it's the latter, then clients perform
> an A (or AAAA, or whatever) lookup...

and in the former, an SRV lookup.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 02:28:16 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25135
	for ; Sun, 23 Jul 2000 02:28:15 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E25B744374; Sun, 23 Jul 2000 02:28:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D149B44362
	for ; Sun, 23 Jul 2000 02:27:59 -0400 (EDT)
Received: from dynamicsoft.com (1Cust192.tnt1.freehold.nj.da.uu.net [63.17.113.192])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA05302;
	Sun, 23 Jul 2000 02:29:20 -0400 (EDT)
Message-ID: <397A9152.3946AC74@dynamicsoft.com>
Date: Sun, 23 Jul 2000 02:31:46 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Howard Hart 
Cc: "Fairlie-Cuninghame, Robert" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Poorman's SIP through firewall.
References:  <3977D869.38F8AFD1@dynamicsoft.com> <39787974.99AC13E3@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I know in practice this kind of thing is done a lot, but its a very bad
slippery slope.

The problem is that once your firewall administrators find out you are
sending stuff they don't want through the firewall on other open ports,
they buy smarter firewalls that do packet inspection to be sure its the
right protocol. Then, application writers tunnel their protocols over
the protocol thats allowed through, and it works again. Then, firewall
vendors put fixes for that, and we're back to square one. Its happened a
lot already for http. In fact, the IESG has an I-D on this subject:

http://search.ietf.org/internet-drafts/draft-moore-using-http-00.txt

Long term, we need solutions that allow network servers for specific
applications (like SIP servers) to cooperate with firewalls to implement
the overall network policy. This is the idea behind foglamps:

http://search.ietf.org/internet-drafts/draft-kuthan-fcp-01.txt

-Jonathan R.



Howard Hart wrote:
> 
> Or you could just park yourself on the standard RealAudio TCP/UDP ports. You'd be
> amazed at how many sites have this particular hole in place due pressure from the
> user population or executive suite, plus most Firewall vendors support it as an
> option out of the box. TCP port 7070 (or just use 80) and incoming/outgoing UDP
> ports 6970-7170.
> 
> Howard Hart
> ipDialog, Inc.
> 
> Jonathan Rosenberg wrote:
> 
> > "Fairlie-Cuninghame, Robert" wrote:
> > >
> > > Yet another SIP firewall proposal:
> > >
> > > _Both_ UA's attempt to open a TCP connection to the address list in each of
> > > the m= lines in the SDP body (eg, m=audio 5000 RTP_TCP/AVP 18) - this is
> > > done regardless of whether the m= line is sendonly, recvonly or sendrecv.
> > > Now one or both TCP connections may succeed. The UA's send their media on
> > > the first TCP connection that successfully connects and should receive media
> > > on either the inbound or outbound TCP connection. For robustness the source
> > > port of the TCP connection should come from a different port than the local
> > > port specified in the SDP body (otherwise you could have two TCP sessions
> > > between the same port pair).
> > >
> > > In the case of the firewall penetration only one of the two TCP connection
> > > attempts will succeed (the one going from inside to outside the firewall)
> > > but since each connection provides a bidirectional pipe then two way media
> > > flow can be achieved.
> > >
> > > Can anyone see any problems with this idea ?
> >
> > 1. still doesn't work with nat
> > 2. doesn't work if both users are behind firewalls (both TCP connections
> > will fail)
> > 3. many firewalls won't let tcp out on dynamic ports; only fixed ones
> > like 80, and then often just from a proxy
> > 4. latency will really suck
> >
> > -Jonathan R.
> > --
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 02:42:59 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01818
	for ; Sun, 23 Jul 2000 02:42:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D36F54437C; Sun, 23 Jul 2000 02:42:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 11D5144376
	for ; Sun, 23 Jul 2000 02:42:36 -0400 (EDT)
Received: from dynamicsoft.com (1Cust192.tnt1.freehold.nj.da.uu.net [63.17.113.192])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA05323;
	Sun, 23 Jul 2000 02:40:16 -0400 (EDT)
Message-ID: <397A93DD.974E2387@dynamicsoft.com>
Date: Sun, 23 Jul 2000 02:42:37 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jo Hornsby 
Cc: Dvir Oren , SIP 
Subject: Re: [SIP] BYE at the callee through proxies
References: <001601bff2f1$bc195480$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jo Hornsby wrote:
> 
> > I don't understand to whom a callee should send its
> > BYE to.
> 
> The Contact address -- this is now mandated in the bis draft.
> 
> > Should it do a user lookup on the From
> > SIP URL?
> 
> I guess in the absence of a Contact address, this is probably
> the best it can do.  (I'm assuming that by "user lookup" you're
> talking about the rules in 1.4.2.)


No, no. When Record-Route is there you will be sending to one of the
addresses in the record-route list.

Dvir's question is coming up because RFC2543 doesn't specify how the UAS
builds a Route header. It only talks about UAC. The bis draft explains
the process for UAS, 6.35.2, which needs better wording but gets the
idea across.

The route, in the end, is based on Contact in the INVITE + Record-Routes
in the INVITE.

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


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 06:05:04 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06859
	for ; Sun, 23 Jul 2000 06:05:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1B4FB4433A; Sun, 23 Jul 2000 06:04:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 96A1944336
	for ; Sun, 23 Jul 2000 06:04:46 -0400 (EDT)
Received: (qmail 26863 invoked by uid 1002); 23 Jul 2000 09:01:21 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 23 Jul 2000 12:01:20 +0300 (IDT)
To: Jonathan Rosenberg 
Cc: SIP 
Subject: Re: [SIP] BYE at the callee through proxies
In-Reply-To: <397A93DD.974E2387@dynamicsoft.com>
References: <001601bff2f1$bc195480$4e34c3c1@ubiquity.co.uk>
	<397A93DD.974E2387@dynamicsoft.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14714.46022.925015.321894@jodie.lucid>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes ("Re: [SIP] BYE at the callee through proxies"):

> the process for UAS, 6.35.2, which needs better wording but gets the
> idea across.

The main problem with the bis, as far as I see it, is that I can't
easily compare it to the RFC.  There is no TOC to compare new
sections, and changes in text inside the bis can't be compared at all.

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 09:10:11 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21860
	for ; Sun, 23 Jul 2000 09:10:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0F5BD44344; Sun, 23 Jul 2000 09:09:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156])
	by lists.bell-labs.com (Postfix) with ESMTP id AE8BF44336
	for ; Sun, 23 Jul 2000 09:09:45 -0400 (EDT)
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id JAA15712;
	Sun, 23 Jul 2000 09:09:28 -0400 (EDT)
Message-ID: <397AEEA0.7C964341@cs.columbia.edu>
Date: Sun, 23 Jul 2000 09:09:52 -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: Dvir Oren 
Cc: Jonathan Rosenberg ,
        SIP 
Subject: Re: [SIP] BYE at the callee through proxies
References: <001601bff2f1$bc195480$4e34c3c1@ubiquity.co.uk>
		<397A93DD.974E2387@dynamicsoft.com> <14714.46022.925015.321894@jodie.lucid>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Dvir Oren wrote:
> 
> Jonathan Rosenberg writes ("Re: [SIP] BYE at the callee through proxies"):
> 
> > the process for UAS, 6.35.2, which needs better wording but gets the
> > idea across.
> 
> The main problem with the bis, as far as I see it, is that I can't
> easily compare it to the RFC.  There is no TOC to compare new
> sections, and changes in text inside the bis can't be compared at all.
> 

I'm not sure which version you are looking at, but the PostScript and
PDF versions of the 2543bis document contain changebars indicating where
changes have been made. In addition, all versions, including the ASCII
versions, include a table of content (at the end, in the case of ASCII,
due to the limitations of nroff) and an annotated list of substantive
and clarification changes (ignoring the minor bug fixes).


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 09:52:24 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01631
	for ; Sun, 23 Jul 2000 09:52:23 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B3F384434E; Sun, 23 Jul 2000 09:51:56 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CD5C74434E
	for ; Sun, 23 Jul 2000 02:22:01 -0400 (EDT)
Received: from dynamicsoft.com (1Cust192.tnt1.freehold.nj.da.uu.net [63.17.113.192])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA05290;
	Sun, 23 Jul 2000 02:22:50 -0400 (EDT)
Message-ID: <397A8FCC.22413375@dynamicsoft.com>
Date: Sun, 23 Jul 2000 02:25:16 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bryan Byerly 
Cc: wtm@research.att.com, kkrama@research.att.com, E.Miller@Cablelabs.com,
        G.Russell@Cablelabs.com, Burcak_Beser@3com.com,
        Michael_Mannette@3com.com, Kurt_Steinbrenner@3com.com, oran@cisco.com,
        fandreas@cisco.com, jpickens@com21.com, pla1waney@gi.com,
        jfellows@gi.com, drevans@securecable.com, keith@netspeak.com,
        sip@lists.bell-labs.com
Subject: Re: [SIP] State: header host should be "hostport"
References: <39787375.673B6A12@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Good catch.

-Jonathan R.

Bryan Byerly wrote:
> 
> Hi guys,
> 
> We've come across a small bug in the draft-dcsgroup-sip-state-01.txt
> while implementing the State: header.
> 
> When multiple proxies run on one server (each listening on a separate
> port), the current BNF for the State: header is insufficient.  "host"
> should be changed to "hostport".
> 
> The BNF in draft-dcsgroup-sip-state-01.txt paragraph 2, section 4.1,
> State Header Syntax should read:
> 
>    The following syntax specification uses the augmented Backus-Naur
>    Form (BNF) as described in RFC-2234 [4].
> 
>         State           = "State" ":" 1#(hostport ";" state-token
>                                 *(";" state-token))
>         state-token     =  token ["=" (*token | quoted-string)]
> 
> If no port is specified, then 5060 should be assumed.
> 
> Please update the draft to reflect this change.
> 
> Thanks for your help!
> Bryan
> 
> Bryan J. Byerly
> byerly@cisco.com
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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



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


From sip-admin@lists.bell-labs.com  Sun Jul 23 16:42:27 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09308
	for ; Sun, 23 Jul 2000 16:42:27 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BB15244348; Sun, 23 Jul 2000 16:42:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id E2F4B44342
	for ; Sun, 23 Jul 2000 16:42:20 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA07393;
	Sun, 23 Jul 2000 16:42:20 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA06183;
	Sun, 23 Jul 2000 14:13:01 -0400 (EDT)
Message-ID: <397B35AD.27D369D9@cs.columbia.edu>
Date: Sun, 23 Jul 2000 14:13:01 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Kjellerstedt 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Inconsistencies and questions regarding latest 2543bis draft
References: <200007200923.LAA08961@saur.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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Peter Kjellerstedt wrote:
> 
> Hello,
> 
> the following are a number of inconsistencies and questions
> that I have found while studying the latest 2543bis draft
> (July 13). I hope they can be fixed/answered.

Thanks for the careful reading. Hopefully, Jonathan L. will soon run his
BNF checker over the current BNF to find any dangling definitions.

> 
> 1) Table 2 is not consistent with the text:
> 
>    In the text about URL parameters it is specified that
>    transport, maddr and ttl MUST NOT be present in From and To
>    headers and in the Request-URI, but still they are listed
>    in table 2 as optitional for the Request-URI.

Table changed.

> 
> 2) In 6.10 (Alert-Info):
> 
>    The syntax looks very odd with upside-down ! and ? around
>    the URI... I suppose they should really be "<" and ">"
>    (as indicated by the example).

LaTeX problem fixed.

> 
> 3) In 6.14 (Call-Info):
> 
>    There should be quotation marks (") around the purpose
>    parameter name in the syntax definition.

Yes, and (unrelated) "tag=" should really be "tag" "=".

> 
>    Must the purpose parameter really be the first one as stated by
>    the grammar, or can it be anywhere among the parameters (as is
>    the case with just about every other parameter list specified
>    in the draft)?
> 

I went through the spec and changed all parameters to the standard

   Foo = "Foo" ":"  something *( ";" foo-param )
   foo-param = ....
             | generic-param

model.


> 4) In 6.15 (Contact) and 11.1 (Behaviour of SIP User Agents):
> 
>    It is stated in 6.15 that a Contact header MUST be present
>    in an INVITE. In 11.1 it is said that you MAY add a Contact
>    to an INVITE...

Changed to MUST.

> 
> 5) In 6.16 (Content-Disposition):
> 
>    The extension-token rule is not defined anywhere. I suppose it
>    should just be a token, but anyway...

Added.

> 
> 6) In 6.35.4 (Record-Route Syntax) and 6.39 (Route):
> 
>    Should the syntax for Record-Route (similar for Route) not be
> 
>       record-route = "Record-Route" ":" 1# (name-addr [rr-extension])
> 
>    instead of
> 
>       record-route = "Record-Route" ":" 1# name-addr [rr-extension]
> 
>    or is the extension really meant for all the recorded routes
>    appearing on the same line, and not each one individually?
>    This is inconsistent with all other similar headers.

Made similar to the other headers:

  Record-Route = "Record-Route" ":" 1# ( name-addr *( ";" rr-param ))
  rr-param     = generic-param


> 
>    Why is it [rr-extension] and not *(';' rr-extension)  ?
>    Is there no possibility of wanting more than one parameter
>    for Record-Route and Route?
> 
> 7) In 6.35.4 (Record-Route Syntax) and 6.47.5 (Via Syntax):
> 
>    The syntax for rr-extension and via-extension could be redefined
>    to use the generic-param rule to keep them consistent with all
>    the other parameters that were changed in this way.

   Now:

     via-extension = generic-param

  The remainder seems to be already in line with the "Foo" example
above.

> 
> //Peter
> 
> ------------------------------------------------------------
> Peter Kjellerstedt       E-Mail: Peter.Kjellerstedt@axis.com
> Axis Communications AB   Phone:  +46 46 272 18 69
> Scheelevagen 34          Fax:    +46 46 13 61 30
> SE-223 63 LUND           URL:    http://www.axis.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 Jul 23 16:45:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09866
	for ; Sun, 23 Jul 2000 16:45:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8B26D44356; Sun, 23 Jul 2000 16:44:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 7938B44351
	for ; Sun, 23 Jul 2000 16:44:49 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA07793;
	Sun, 23 Jul 2000 16:44:42 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA05076;
	Sun, 23 Jul 2000 13:03:40 -0400 (EDT)
Message-ID: <397B256C.1CA49F4D@cs.columbia.edu>
Date: Sun, 23 Jul 2000 13:03:40 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Dvir Oren , SIP 
Subject: Re: [SIP] Display Name
References: <14711.29353.987564.881674@jodie.lucid> <3977E1B4.E0FED8E7@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> I believe it has to be a quoted string if it contains non-token
> characters:
> 
> Contact: "< this is a test" 

To amplify: The spec definition is 

   display-name   = *token | quoted-string

which, I believe, addresses this unambiguously.

-- 
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 Jul 23 16:55:00 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11964
	for ; Sun, 23 Jul 2000 16:55:00 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D56A544367; Sun, 23 Jul 2000 16:54:35 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id C053C44360
	for ; Sun, 23 Jul 2000 16:54:32 -0400 (EDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA07154;
	Sun, 23 Jul 2000 13:54:16 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA14899; Sun, 23 Jul 2000 13:54:07 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14715.23407.572199.521488@thomasm-u1.cisco.com>
Date: Sun, 23 Jul 2000 13:54:07 -0700 (PDT)
To: Jonathan Rosenberg 
Cc: Howard Hart ,
        "Fairlie-Cuninghame, Robert" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Poorman's SIP through firewall.
In-Reply-To: <397A9152.3946AC74@dynamicsoft.com>
References: 
	<3977D869.38F8AFD1@dynamicsoft.com>
	<39787974.99AC13E3@ipdialog.com>
	<397A9152.3946AC74@dynamicsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:
 > Long term, we need solutions that allow network servers for specific
 > applications (like SIP servers) to cooperate with firewalls to implement
 > the overall network policy. This is the idea behind foglamps:
 > 
 > http://search.ietf.org/internet-drafts/draft-kuthan-fcp-01.txt

   And when the e-2-e applications encrypt the
   application payloads?

   This entire thing strikes me as entirely
   unsolvable: two colluding parties can always
   defeat a net.marm. I saw an article on how
   people were transmitting covert messages using
   unused/mungable parts of IP and TCP headers.
   The possibilities seem limitless.

		     Mike


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


From sip-admin@lists.bell-labs.com  Sun Jul 23 21:11:51 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06921
	for ; Sun, 23 Jul 2000 21:11:51 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5ADBA44350; Sun, 23 Jul 2000 21:11:22 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from june.idc1.level3.com (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 581B94433C
	for ; Sun, 23 Jul 2000 21:11:19 -0400 (EDT)
Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140])
	by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id BAA28246;
	Mon, 24 Jul 2000 01:11:15 GMT
From: Jon.Peterson@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id TAA11296;
	Sun, 23 Jul 2000 19:11:14 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Sun, 23 Jul 2000 19:12:57 -0600
Message-ID: <87A245E94948D3118DE30008C716B01301523A35@c0005v1idc1.oss.level3.com>
To: jdrosen@dynamicsoft.com, mfox@nuera.com
Cc: mat@cisco.com, sip@lists.bell-labs.com
Subject: RE: [SIP] How to stop a Lawnmower Man attack?
Date: Sun, 23 Jul 2000 19:11:12 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


My draft 

http://search.ietf.org/internet-drafts/draft-jfp-sipfw-policy-00.txt 

addresses the administration of certain policies (including
application-layer throttling and similar mechanisms) located at the points
of admission to a network. It is specifically predicated on the idea that a
well-managed SIP network will have rules that characterize the SIP traffic
that traverses particular network edges. Rather than recommending any
additions to the protocol, my draft suggests architectures in which the
deployment of policies in concert with standard firewalls can be modular and
reasonable painless.

I would be interested in hearing feedback regarding the applicability of my
draft to this sort of problem.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Sunday, July 23, 2000 1:32 AM
To: Fox, Mike
Cc: Michael Thomas; sip@lists.bell-labs.com
Subject: Re: [SIP] How to stop a Lawnmower Man attack?




"Fox, Mike" wrote:
> 
> Oops I need correct one sentence...
> >> I would like to be clear in that I'm not trying to suggest
> >> that SIP does [ NOT ] support administrative control.
> 
> >    I don't see how the protocol itself can help. I can
> >    see pretty simple call gapping measures at proxies,
> >    etc, help though but those don't require any new
> >    protocol mechanisms. Also: a UAS can always insist
> >    that the initial INVITE come through a trusted
> >    proxy rather than directly from the UAC. Assuming
> >    that proxies are more trustworthy because they at
> >    least have some admin behind them, you could limit
> >    the zombie attack as above.
> 
> In other words a Gate Keeper. This is my conclusion too, but so far there
is
> no GK element proscribed for SIP, why not?

There is no need to define an additional element, or standardize
interfaces or protocols for it. This role can be played by a proxy. I
suspect, in fact, there are many ingenious ways you can build logic into
a proxy to prevent such attacks - call setup rate thresholds, etc.
Leaving these to the imaginations of implementors as a source of vendor
differentiation, rather than standardizing them in a protocol document,
seems a better way to go. 

That said, I do agree it would be nice to have a document that describes
the threats in a SIP system, with some discussions on protocol
mechanisms that might exist to alleviate them. This would be an
informational document. It was my hope that the security task force
(which has been a bit quiet as of late) would generate such a 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: (732) 741-7244
http://www.dynamicsoft.com


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


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


From sip-admin@lists.bell-labs.com  Mon Jul 24 00: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 ESMTP id AAA20321
	for ; Mon, 24 Jul 2000 00:24:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DB72244345; Mon, 24 Jul 2000 00:23:41 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8DB2D4433C
	for ; Mon, 24 Jul 2000 00:23:38 -0400 (EDT)
Received: from dynamicsoft.com (p173.stsn.com [208.32.226.173] (may be forged))
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA01138;
	Mon, 24 Jul 2000 00:24:53 -0400 (EDT)
Message-ID: <397BC5AC.CA5C892A@dynamicsoft.com>
Date: Mon, 24 Jul 2000 00:27:24 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas 
Cc: Howard Hart ,
        "Fairlie-Cuninghame, Robert" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Poorman's SIP through firewall.
References: 
		<3977D869.38F8AFD1@dynamicsoft.com>
		<39787974.99AC13E3@ipdialog.com>
		<397A9152.3946AC74@dynamicsoft.com> <14715.23407.572199.521488@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Michael Thomas wrote:
> 
> Jonathan Rosenberg writes:
>  > Long term, we need solutions that allow network servers for specific
>  > applications (like SIP servers) to cooperate with firewalls to implement
>  > the overall network policy. This is the idea behind foglamps:
>  >
>  > http://search.ietf.org/internet-drafts/draft-kuthan-fcp-01.txt
> 
>    And when the e-2-e applications encrypt the
>    application payloads?

Sorry, can't hear you. What? Hellooooo? Heloooooooo?

Firewalls and NATs, simply put, do not fit well into the end to end
architecture. So, if you build security based on e2e models, its no big
surprise nats and firewalls screw things up.

So, its a tradeoff. Want security - get few features and services from
network devices that (for good or bad) want to munge and look at your
packets. 

If I could make these devices go away, I would. But they are here, and I
need to live with them.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Mon Jul 24 04:39:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12976
	for ; Mon, 24 Jul 2000 04:39:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 47EDF44348; Mon, 24 Jul 2000 04:39:18 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id E42E844338
	for ; Mon, 24 Jul 2000 04:39:14 -0400 (EDT)
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id JAA08504; Mon, 24 Jul 2000 09:37:03 +0100 (BST)
Message-ID: <397C002F.FF57F091@ubiquity.net>
Date: Mon, 24 Jul 2000 09:37:03 +0100
From: Neil Deason 
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Jo Hornsby , Shail Bhatnagar ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <000701bff332$04f01320$4e34c3c1@ubiquity.co.uk> <397A8FAC.EE482A4E@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:
> 
> Jo Hornsby wrote:
> >
> > > If you put an IP address into the maddr parameter, yes, the port
> > > number will need to be there if its not 5060. If you put a domain
> > > name, you will not need it if you wish to rely on SRV records. If
> > > you are relying on A records, again, you'll need it there.
> > > Record-routing with domain names that point to SRV records can be
> > > both good and bad. If may cause subsequent requests to go to a
> > > different server. Good for failover, bad if you don't have
> > > state replication mechanisms in the back end between servers.
> >
> > Is it possible to rely on SRV _at all_ with Record-Route, though,
> > since the maddr parameter is a MUST?
> 
> Yes, as I said, since the maddr itself can contain a domain name.
> 
> >
> > As far as I can tell from 1.4.2, the maddr is either going to be
> > an IP or a host name; if it's the latter, then clients perform
> > an A (or AAAA, or whatever) lookup...
> 
> and in the former, an SRV lookup.

I thought that if the maddr is the former, i.e. an IP address,
the client is going to contact the server directly at that given
address. If it is a host name the client queries the DNS server
for address records (A RR's, AAAA RR's) for the host portion of
the maddr. Therefore no lookup for SRV records for a SIP server
is done in Record-Routing.

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 Jul 24 04:41:31 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13363
	for ; Mon, 24 Jul 2000 04:41:31 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C36334435E; Mon, 24 Jul 2000 04:41:29 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.speedventures.com (unknown [212.75.74.99])
	by lists.bell-labs.com (Postfix) with ESMTP id 503E64435B
	for ; Mon, 24 Jul 2000 04:41:26 -0400 (EDT)
Received: from HOTSIP6XW5F2VJ (212.28.214.254 [212.28.214.254]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 3WF8A1S2; Mon, 24 Jul 2000 10:36:30 +0200
Message-ID: <001a01bff54a$d71c14b0$fed61cd4@HOTSIP6XW5F2VJ>
From: "Johan Liseborn" 
To: "Jonathan Rosenberg" ,
        "Dialout.net (David Yon)" 
Cc: 
References: <4.3.2.7.2.20000721154828.00da0e40@hither.rfdsoftware.com> <397A7781.5AFDA4CF@dynamicsoft.com>
Subject: Re: [SIP] Quake-over-SIP?
Date: Mon, 24 Jul 2000 10:40:13 +0200
Organization: Hotsip AB
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> >         Is there spec/docs for how the Internet multi-player Quake
support uses
> > SIP?  Anyone know where I can find it?  I heard about this at VON and
have
> > come up empty in my web searching.
>
> I asked the folks who worked on it to submit an I-D for the meeting, but
> I haven't seen anything. It would be very nice to see that.

Hmm, yes we had the intention of finishing the draft to this meeting,
but unfortunately there was not enough time. There *is* an early
version of a draft (and, of course, our implementation of it :-),
but I feel that it needs some more work before making it publicly
available.

> >         I'm particularly interesting to see if they are using TCP-based
transport
> > (for the media, not SIP itself) and how they solved some of the
impedance
> > mismatches between SDP and TCP-based transports.
>
> SDP is not a transport, so comparing it to TCP is apples/oranges.
> Apparently you can simply start quake with command line parameters that
> point to a server, game name, etc. It is my understanding that they
> simply passed these parameters in SDP. Something like:
>
> m=application 3726 tcp quake
> a=fmtp:quake 
>
> would be my guess about how it was accomplished.

Your guess is correct. This is basically how we do it. The tricky thing
is what parameters you need. There are many different games and
many different modes of the games (such as deathmatch, capture the
flag, domination, etc), where different games and modes require
different types of parameteres (such as player names, teams, maps,
etc).

Looking forward to playing Quake with everybody on the SIP list!

/johan

--
Johan Liseborn
CTO, Hotsip AB
phone: +46 (0)8 555 10 702
mobile: +46 (0)739 888 160



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


From sip-admin@lists.bell-labs.com  Mon Jul 24 04:53:01 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15804
	for ; Mon, 24 Jul 2000 04:53:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9CA3A44369; Mon, 24 Jul 2000 04:52:28 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 1FB9144362
	for ; Mon, 24 Jul 2000 04:52:23 -0400 (EDT)
Received: (qmail 27831 invoked by uid 1002); 24 Jul 2000 08:48:49 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 24 Jul 2000 11:48:47 +0300 (IDT)
To: SIP 
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14716.525.940751.566898@jodie.lucid>
Subject: [SIP] Proxy ACKs
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

When a proxy receives a non-success final reply, to whom should it
send the ACK?  Should it look up the Request-URI from the INVITE, and
send it to there?  Should it check Contact?  Record-Route?

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Mon Jul 24 05:09:26 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19309
	for ; Mon, 24 Jul 2000 05:09:26 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9190B4435E; Mon, 24 Jul 2000 05:09:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 3070644338
	for ; Mon, 24 Jul 2000 05:08:59 -0400 (EDT)
Received: (qmail 27842 invoked by uid 1002); 24 Jul 2000 09:05:26 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 24 Jul 2000 12:05:23 +0300 (IDT)
To: SIP 
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14716.1457.96180.675876@jodie.lucid>
Subject: [SIP] Comparing URLs
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Are the following two URLs the same?




Although the RFC says that the IP address from a DNS lookup does not
equal the hostname of that lookup, it doesn't really say anything
about maddr.

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Mon Jul 24 05: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 ESMTP id FAA23088
	for ; Mon, 24 Jul 2000 05:27:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3E39C44362; Mon, 24 Jul 2000 05:26:56 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id DC43A4434A
	for ; Mon, 24 Jul 2000 05:26:51 -0400 (EDT)
Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA11853; Mon, 24 Jul 2000 10:24:48 +0100 (BST)
From: Gethin Liddell 
Organization: Ubiquity Software Corp.
To: Dvir Oren , SIP 
Subject: Re: [SIP] Comparing URLs
Date: Mon, 24 Jul 2000 10:13:14 +0100
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
References: <14716.1457.96180.675876@jodie.lucid>
In-Reply-To: <14716.1457.96180.675876@jodie.lucid>
MIME-Version: 1.0
Message-Id: <00072410201500.06449@gethin>
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

On Mon, 24 Jul 2000, Dvir Oren wrote:
> Are the following two URLs the same?
> 
> 
> 

No, these two are definitely not the same.

Section 2 describes URL equality and is pretty black and white on this
subject:

"user, password, host, port and any url-parameter parameters of the
URI must match."

here the hosts do not match, irrespective of what parameters are
present.

> 
> Although the RFC says that the IP address from a DNS lookup does not
> equal the hostname of that lookup, it doesn't really say anything
> about maddr.

-- 
Gethin Liddell
Ubiquity Software Corporation

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


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


From sip-admin@lists.bell-labs.com  Mon Jul 24 05:30:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23873
	for ; Mon, 24 Jul 2000 05:30:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 44E6644372; Mon, 24 Jul 2000 05:30:30 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 5ECE14436D
	for ; Mon, 24 Jul 2000 05:30:24 -0400 (EDT)
Received: (qmail 27894 invoked by uid 1002); 24 Jul 2000 09:26:49 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 24 Jul 2000 12:26:48 +0300 (IDT)
To: SIP 
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14716.2357.177860.970744@jodie.lucid>
Subject: [SIP] maddr and NATs
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

If a SIP entity adds an 'maddr' parameters, and that entity is
behind a NAT, the address of the maddr will not work.  I'm assuming
here that the SIP agent adds an IP address. There is also a problem 
when the client adds a Contact, and it is behind a NAT.

For Via fields - there is a received tag.  But for Contact, nobody will 
check that address.

It seems to me like there would be better chances passing a NAT if
there were no Contacts.

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Mon Jul 24 06:05:30 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01358
	for ; Mon, 24 Jul 2000 06:05:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EE2A94435E; Mon, 24 Jul 2000 06:05:20 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id EDDFD44338
	for ; Mon, 24 Jul 2000 06:05:16 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id LAA13490; Mon, 24 Jul 2000 11:03:19 +0100 (BST)
From: "Jo Hornsby" 
To: "Dvir Oren" , "SIP" 
Subject: RE: [SIP] Proxy ACKs
Date: Mon, 24 Jul 2000 11:03:18 +0100
Message-ID: <000f01bff556$63e88a80$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: <14716.525.940751.566898@jodie.lucid>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> When a proxy receives a non-success final reply, to whom should it
> send the ACK?

It should send it to the same place that it sent the corresponding
INVITE.  Since the only type of proxy that is allowed to originate
ACKs is a stateful proxy, this is trivial.

HTH,


 - Jo.



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


From sip-admin@lists.bell-labs.com  Mon Jul 24 06: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 ESMTP id GAA01918
	for ; Mon, 24 Jul 2000 06:08:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EADCC44377; Mon, 24 Jul 2000 06:06:59 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id D59C44436E
	for ; Mon, 24 Jul 2000 06:06:55 -0400 (EDT)
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id LAA13793; Mon, 24 Jul 2000 11:05:05 +0100 (BST)
Message-ID: <397C14D0.EE94C286@ubiquity.net>
Date: Mon, 24 Jul 2000 11:05:04 +0100
From: Neil Deason 
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com> <39782CCE.4BFF8A3E@ubiquity.net> <3978775A.BC475B21@dynamicsoft.com> <39787C95.481C3BDD@ubiquity.net> <397A8F76.BE9DB8AD@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Neil Deason wrote:
> >
> > >
> > > If you put an IP address into the maddr parameter, yes, the port number
> > > will need to be there if its not 5060. If you put a domain name, you
> > > will not need it if you wish to rely on SRV records. If you are relying
> > > on A records, again, you'll need it there. Record-routing with domain
> > > names that point to SRV records can be both good and bad. If may cause
> > > subsequent requests to go to a different server. Good for failover, bad
> > > if you don't have state replication mechanisms in the back end between
> > > servers.
> >
> > What about on reverse request paths where components other
> > than the maddr param are taken from the originating name-addr
> > value (i.e. Contact header or From header if there is no
> > Contact). In this case isn't any port info placed in the
> > Request-URI by a proxy wanting to be on the route lost.
> 
> I can't seem to parse this response. Can you rephrase?

I was thinking about the possible effect of a proxy server
relying on the mechanism of writing it's port number, if it is
not 5060, in the Request-URI. In the case of reverse request
paths wont this be useless? According to Section 6.35.2 ...

"Since the URIs contained in the Record-Route are not useful for
the reverse request path, the UA fills all other components of
the Route name-addr value with the originating name-addr value.
The originating name-addr value is the name-addr value found in
the Contact header of the request or the From header field, if
there is no Contact header field."

If the Contact header, or potentially the From, contain a port
number different to that which the proxy is listening on the
request will be lost.

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 Jul 24 06:57:40 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16027
	for ; Mon, 24 Jul 2000 06:57:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CB4904435D; Mon, 24 Jul 2000 06:57:35 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id AF91B44338
	for ; Mon, 24 Jul 2000 06:57:32 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0FY7006017RWPK@firewall.mcit.com> for sip@lists.bell-labs.com; Mon,
 24 Jul 2000 10:57:32 +0000 (GMT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FY700KCV7RV7W@firewall.mcit.com>; Mon,
 24 Jul 2000 10:57:31 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 id <0FY700C017RV1D@pmismtp01.wcomnet.com>; Mon,
 24 Jul 2000 10:57:31 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0FY700C017RU1A@pmismtp01.wcomnet.com>;
 Mon, 24 Jul 2000 10:57:31 +0000 (GMT)
Received: from C25776A ([166.46.19.175])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with SMTP id <0FY70034K7RKT0@pmismtp01.wcomnet.com>; Mon,
 24 Jul 2000 10:57:22 +0000 (GMT)
Date: Mon, 24 Jul 2000 05:57:09 -0500
From: Henry Sinnreich 
Subject: RE: [SIP] Quake-over-SIP?
In-reply-to: <001a01bff54a$d71c14b0$fed61cd4@HOTSIP6XW5F2VJ>
To: Johan Liseborn ,
        Jonathan Rosenberg ,
        "Dialout.net (David Yon)" 
Cc: sip@lists.bell-labs.com
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Games are a fascinating new application for SIP!
Am looking forward to your draft.

Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>Johan Liseborn
>Sent: Monday, July 24, 2000 3:40 AM
>To: Jonathan Rosenberg; Dialout.net (David Yon)
>Cc: sip@lists.bell-labs.com
>Subject: Re: [SIP] Quake-over-SIP?
>
>
>> >         Is there spec/docs for how the Internet
>multi-player Quake
>support uses
>> > SIP?  Anyone know where I can find it?  I heard
>about this at VON and
>have
>> > come up empty in my web searching.
>>
>> I asked the folks who worked on it to submit an I-D
>for the meeting, but
>> I haven't seen anything. It would be very nice to see that.
>
>Hmm, yes we had the intention of finishing the draft
>to this meeting,
>but unfortunately there was not enough time. There
>*is* an early
>version of a draft (and, of course, our implementation
>of it :-),
>but I feel that it needs some more work before making
>it publicly
>available.
>
>> >         I'm particularly interesting to see if
>they are using TCP-based
>transport
>> > (for the media, not SIP itself) and how they
>solved some of the
>impedance
>> > mismatches between SDP and TCP-based transports.
>>
>> SDP is not a transport, so comparing it to TCP is
>apples/oranges.
>> Apparently you can simply start quake with command
>line parameters that
>> point to a server, game name, etc. It is my
>understanding that they
>> simply passed these parameters in SDP. Something like:
>>
>> m=application 3726 tcp quake
>> a=fmtp:quake 
>>
>> would be my guess about how it was accomplished.
>
>Your guess is correct. This is basically how we do it.
>The tricky thing
>is what parameters you need. There are many different games and
>many different modes of the games (such as deathmatch,
>capture the
>flag, domination, etc), where different games and modes require
>different types of parameteres (such as player names,
>teams, maps,
>etc).
>
>Looking forward to playing Quake with everybody on the
>SIP list!
>
>/johan
>
>--
>Johan Liseborn
>CTO, Hotsip AB
>phone: +46 (0)8 555 10 702
>mobile: +46 (0)739 888 160
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/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 Jul 24 07:29:30 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24954
	for ; Mon, 24 Jul 2000 07:29:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B758A4436B; Mon, 24 Jul 2000 07:29:25 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from polaris.shore.net (polaris.shore.net [207.244.124.105])
	by lists.bell-labs.com (Postfix) with ESMTP id CEEE444338
	for ; Mon, 24 Jul 2000 07:29:22 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by polaris.shore.net with esmtp (Exim)
	id 13GgQ4-0006Ry-00; Mon, 24 Jul 2000 07:29:12 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id HAA18445;
	Mon, 24 Jul 2000 07:22:33 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000724065902.00d2fa60@webhost.tactical-sw.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Jul 2000 07:13:25 -0400
To: "Johan Liseborn" ,
        "Jonathan Rosenberg" 
From: David Yon 
Subject: Re: [SIP] Quake-over-SIP?
Cc: 
In-Reply-To: <001a01bff54a$d71c14b0$fed61cd4@HOTSIP6XW5F2VJ>
References: <4.3.2.7.2.20000721154828.00da0e40@hither.rfdsoftware.com>
 <397A7781.5AFDA4CF@dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

         Answering both at once to reduce the traffic here...

At 10:40 AM 7/24/00 +0200, Johan Liseborn wrote:

> > >         I'm particularly interesting to see if they are using TCP-based
>transport
> > > (for the media, not SIP itself) and how they solved some of the
>impedance
> > > mismatches between SDP and TCP-based transports.
> >
> > SDP is not a transport, so comparing it to TCP is apples/oranges.
> > Apparently you can simply start quake with command line parameters that
> > point to a server, game name, etc. It is my understanding that they
> > simply passed these parameters in SDP. Something like:
> >

         Well yes, my ambiguous phrasing aside, of *course* SDP is not a 
transport.  That said, SDP is not particularly well suited to *describe* a 
media transport that is TCP based.  It wants to assume a transport where no 
connection needs to be brought up, the major omission being who is the 
initiator of the connection and who should be the listener.  Forget all 
about RTP---I'm talking about a media transport which can be deployed using 
a single TCP connection between the endpoints.


> > m=application 3726 tcp quake
> > a=fmtp:quake 
> >
> > would be my guess about how it was accomplished.
>
>Your guess is correct. This is basically how we do it. The tricky thing
>is what parameters you need. There are many different games and
>many different modes of the games (such as deathmatch, capture the
>flag, domination, etc), where different games and modes require
>different types of parameteres (such as player names, teams, maps,
>etc).

         Ok, so I assume that the two endpoints bring up a TCP connection 
in order to play the game?  If so, how does the above SDP describe which 
endpoint does the "connect" and which does the "accept"?  Is TCP a 
well-known SDP transport type?  Would an off-the-shelf SIP proxy that's 
managing a firewall/NAT know how to open up a port to let this through?

         I don't mean this as a criticism of the above approach, we will 
probably end up doing something similar.  I want to make sure that we are 
as interoperable as possible, and the prevalence of RTP/UDP transports in 
SIP networks has me concerned that an odd-duck TCP-based transport will 
cause breakage if there is no standard model to be followed.


David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net



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


From sip-admin@lists.bell-labs.com  Mon Jul 24 10:18:22 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04462
	for ; Mon, 24 Jul 2000 10:18:21 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2A4424435E; Mon, 24 Jul 2000 10:17:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5CB0844338
	for ; Mon, 24 Jul 2000 10:17:09 -0400 (EDT)
Received: from DELSOL ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id KAA02947;
	Mon, 24 Jul 2000 10:18:30 -0400 (EDT)
From: "Daniel Gardner" 
To: "Henning Schulzrinne" ,
        "Peter Kjellerstedt" 
Cc: 
Subject: RE: [SIP] Inconsistencies and questions regarding latest 2543bis draft
Date: Mon, 24 Jul 2000 10:15:33 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-reply-to: <397B35AD.27D369D9@cs.columbia.edu>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Should the section on locating a server (1.4.2) be updated to reflect
point (1) below?

Dan Gardner

-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning Schulzrinne
Sent: Sunday, July 23, 2000 2:13 PM
To: Peter Kjellerstedt
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Inconsistencies and questions regarding latest
2543bis draft


Peter Kjellerstedt wrote:
> 
> Hello,

> the following are a number of inconsistencies and questions
> that I have found while studying the latest 2543bis draft
> (July 13). I hope they can be fixed/answered.

Thanks for the careful reading. Hopefully, Jonathan L. will soon run his
BNF checker over the current BNF to find any dangling definitions.

> 
> 1) Table 2 is not consistent with the text:
> 
>    In the text about URL parameters it is specified that
>    transport, maddr and ttl MUST NOT be present in From and To
>    headers and in the Request-URI, but still they are listed
>    in table 2 as optitional for the Request-URI.

Table changed.

> 
> 2) In 6.10 (Alert-Info):
> 
>    The syntax looks very odd with upside-down ! and ? around
>    the URI... I suppose they should really be "<" and ">"
>    (as indicated by the example).

LaTeX problem fixed.

> 
> 3) In 6.14 (Call-Info):
> 
>    There should be quotation marks (") around the purpose
>    parameter name in the syntax definition.

Yes, and (unrelated) "tag=" should really be "tag" "=".

> 
>    Must the purpose parameter really be the first one as stated by
>    the grammar, or can it be anywhere among the parameters (as is
>    the case with just about every other parameter list specified
>    in the draft)?
> 

I went through the spec and changed all parameters to the standard

   Foo = "Foo" ":"  something *( ";" foo-param )
   foo-param = ....
             | generic-param

model.


> 4) In 6.15 (Contact) and 11.1 (Behaviour of SIP User Agents):
> 
>    It is stated in 6.15 that a Contact header MUST be present
>    in an INVITE. In 11.1 it is said that you MAY add a Contact
>    to an INVITE...

Changed to MUST.

> 
> 5) In 6.16 (Content-Disposition):
> 
>    The extension-token rule is not defined anywhere. I suppose it
>    should just be a token, but anyway...

Added.

> 
> 6) In 6.35.4 (Record-Route Syntax) and 6.39 (Route):
> 
>    Should the syntax for Record-Route (similar for Route) not be
> 
>       record-route = "Record-Route" ":" 1# (name-addr [rr-extension])
> 
>    instead of
> 
>       record-route = "Record-Route" ":" 1# name-addr [rr-extension]
> 
>    or is the extension really meant for all the recorded routes
>    appearing on the same line, and not each one individually?
>    This is inconsistent with all other similar headers.

Made similar to the other headers:

  Record-Route = "Record-Route" ":" 1# ( name-addr *( ";" rr-param ))
  rr-param     = generic-param


> 
>    Why is it [rr-extension] and not *(';' rr-extension)  ?
>    Is there no possibility of wanting more than one parameter
>    for Record-Route and Route?
> 
> 7) In 6.35.4 (Record-Route Syntax) and 6.47.5 (Via Syntax):
> 
>    The syntax for rr-extension and via-extension could be redefined
>    to use the generic-param rule to keep them consistent with all
>    the other parameters that were changed in this way.

   Now:

     via-extension = generic-param

  The remainder seems to be already in line with the "Foo" example
above.

> 
> //Peter
> 
> ------------------------------------------------------------
> Peter Kjellerstedt       E-Mail: Peter.Kjellerstedt@axis.com
> Axis Communications AB   Phone:  +46 46 272 18 69
> Scheelevagen 34          Fax:    +46 46 13 61 30
> SE-223 63 LUND           URL:    http://www.axis.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



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


From sip-admin@lists.bell-labs.com  Mon Jul 24 14:02:02 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12665
	for ; Mon, 24 Jul 2000 14:02:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3022F4435B; Mon, 24 Jul 2000 14:01:00 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from polaris.shore.net (polaris.shore.net [207.244.124.105])
	by lists.bell-labs.com (Postfix) with ESMTP id 9332544338
	for ; Mon, 24 Jul 2000 14:00:56 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by polaris.shore.net with esmtp (Exim)
	for sip@lists.bell-labs.com
	id 13GmWz-0001jB-00; Mon, 24 Jul 2000 14:00:45 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id NAA18756
	for ; Mon, 24 Jul 2000 13:54:11 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000724140033.00ae36f0@hither.rfdsoftware.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Jul 2000 14:01:16 -0400
To: sip@lists.bell-labs.com
From: David Yon 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] SIP and T.38?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

	Are there any I-D's or other precedents for signalling a T.38 fax session 
using SIP?

David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net



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


From sip-admin@lists.bell-labs.com  Mon Jul 24 14:13:14 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15547
	for ; Mon, 24 Jul 2000 14:13:14 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B55094436E; Mon, 24 Jul 2000 14:12:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com [192.84.19.131])
	by lists.bell-labs.com (Postfix) with ESMTP id 88F9A44360
	for ; Mon, 24 Jul 2000 14:12:02 -0400 (EDT)
Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130])
	by mail-gw.NetergyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19883;
	Mon, 24 Jul 2000 11:11:58 -0700 (PDT)
Received: from 8x8.com (symph202.8x8.com [207.82.37.202])
	by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id LAA23842;
	Mon, 24 Jul 2000 11:11:57 -0700 (PDT)
Message-ID: <397C861C.202504E7@8x8.com>
Date: Mon, 24 Jul 2000 11:08:28 -0700
From: Marc Petit-Huguenin 
Organization: Netergy Networks Inc.
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.17 i686)
X-Accept-Language: fr-FR, fr, en
MIME-Version: 1.0
To: David Yon 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and T.38?
References: <4.3.2.7.2.20000724140033.00ae36f0@hither.rfdsoftware.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

David Yon wrote:
> 
>         Are there any I-D's or other precedents for signalling a T.38 fax session
> using SIP?

Seems that a T.38 Annex D (SIP/SDP) is in progress at the ITU.

See also http://www.ietf.org/proceedings/99nov/46th-99nov-ietf-141.html

> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> yon@dialout.net
> 

-- 
Marc Petit-Huguenin
Home: mailto:petithug@cyberservices.com
Work: mailto:petithug@8x8.com
"So much to do and so little time" The Joker - Batman (The Movie)


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


From sip-admin@lists.bell-labs.com  Mon Jul 24 16:21:49 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25036
	for ; Mon, 24 Jul 2000 16:21:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A948E44350; Mon, 24 Jul 2000 16:21:35 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by lists.bell-labs.com (Postfix) with ESMTP id 8DBF344338
	for ; Mon, 24 Jul 2000 16:21:32 -0400 (EDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Mon, 24 Jul 2000 15:17:54 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id ; Mon, 24 Jul 2000 15:19:21 -0500
Message-ID: <456E6DB7180ED3118A670000F8BDCA29021BB192@zcard00p.ca.nortel.com>
From: "Glenn Parsons" 
To: David Yon ,
        "'Marc Petit-Huguenin'" ,
        "'Flemming Andreasen'" 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP and T.38?
Date: Mon, 24 Jul 2000 15:19:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF5AC.7117D2F0"
X-Orig: 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF5AC.7117D2F0
Content-Type: text/plain

	T.38 Annex D (SIP/SDP Call Establishment Procedures) was done in
February and should soon be at:
	http://www.itu.int/itudoc/itu-t/rec/t/t_38am2.html

	It is not there yet because it was bundled in an Amendment with T.38
Annex E (H.248/Megaco) which was delayed... 

	In the meantime, you can look at the 'draft' version and the IANA
SDP registrations at:
	ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/February00/

	Cheers,
	Glenn.

> David Yon wrote:
> > 
> >         Are there any I-D's or other precedents for signalling a T.38
> fax session
> > using SIP?
> 
> Seems that a T.38 Annex D (SIP/SDP) is in progress at the ITU.
> 
> See also http://www.ietf.org/proceedings/99nov/46th-99nov-ietf-141.html
> 
> > 
> > David Yon
> > Chief Technical Officer
> > Dialout.Net, Inc.
> > yon@dialout.net
> > 
> 
> -- 
> Marc Petit-Huguenin
> Home: mailto:petithug@cyberservices.com
> Work: mailto:petithug@8x8.com
> "So much to do and so little time" The Joker - Batman (The Movie)
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 

------_=_NextPart_001_01BFF5AC.7117D2F0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [SIP] SIP and T.38?





------_=_NextPart_001_01BFF5AC.7117D2F0--


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


From sip-admin@lists.bell-labs.com  Mon Jul 24 16:34:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28481
	for ; Mon, 24 Jul 2000 16:34:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A0C484436A; Mon, 24 Jul 2000 16:33:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 2F4A64435F
	for ; Mon, 24 Jul 2000 16:33:42 -0400 (EDT)
Received: from vovida.com (a98.vovida.com [209.237.8.98] (may be forged))
	by repulse.cnchost.com
	id QAA21021; Mon, 24 Jul 2000 16:33:41 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <397CA827.B1FAC243@vovida.com>
Date: Mon, 24 Jul 2000 13:33:43 -0700
From: Sunitha Kumar 
Organization: Vovida Networks
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: SIPbell-labs 
Content-Type: multipart/alternative;
 boundary="------------A0A1251D318135A82CC96630"
Subject: [SIP] Question on Contact, and Route in the draft.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


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

Quoting from pg:68 ,
If the request featured a Contact header field, the Contact header value
is appended to the Route header list.

Is this the initial request? If that is so, it cannot have the Route
header list.

If this is the next request from the same end point, then the Route
header list is
indeed present(assuming we have had proxies add Record-Route). however,
in this
case, it does not make sense to add the Contact to the Route list, (
since the Route list contains the route to get to the destination).

Could some one explain this.

thanks much.

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



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



Quoting from pg:68 ,

If the request featured a Contact header field, the Contact header
value is appended to the Route header list.

Is this the initial request? If that is so, it cannot have the Route
header list.

If this is the next request from the same end point, then the Route
header list is

indeed present(assuming we have had proxies add Record-Route). however,
in this

case, it does not make sense to add the Contact to the Route list,
( since the Route list contains the route to get to the destination).

Could some one explain this.

thanks much.

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

 

--------------A0A1251D318135A82CC96630--



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


From sip-admin@lists.bell-labs.com  Mon Jul 24 17:26:26 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12070
	for ; Mon, 24 Jul 2000 17:26:25 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D719C4435F; Mon, 24 Jul 2000 17:26:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104])
	by lists.bell-labs.com (Postfix) with ESMTP id 7F48544338
	for ; Mon, 24 Jul 2000 17:26:08 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by nautilus.shore.net with esmtp (Exim)
	id 13Gpji-0002Lr-00; Mon, 24 Jul 2000 17:26:06 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id RAA18889;
	Mon, 24 Jul 2000 17:19:32 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000724172644.00d12230@webhost.tactical-sw.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Jul 2000 17:26:56 -0400
To: "Glenn Parsons" 
From: David Yon 
Subject: RE: [SIP] SIP and T.38?
Cc: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

         Thanks for the pointer, that's extremely helpful.  What's not 
clear from reading the draft is how the Annex solves some of the problems 
with SDP specifying a TCP transport.

         I'm happy to see that "TCP" will become a registered name, but I 
don't see how the direction of the initial connection is negotiated.  I.e., 
which side of the T.38 does the "connect" and which does the "accept"?  Is 
this described in the proposed extensions to SDP?  If so, where?  If not, 
was the idea that the direction of the connect would be implicit by the 
rest of the SDP media description (i.e., if it's t38 over TCP, then the 
caller always does the connect)?

         Does anyone else on the list think it might be a good idea to 
standardize this as part of how one describes a TCP-based transport in 
SDP?  It seems like it couldn't hurt to make it an explicit part of the SDP 
description.

At 03:19 PM 7/24/00 -0500, you wrote:
>T.38 Annex D (SIP/SDP Call Establishment Procedures) was done in February 
>and should soon be at: 
>http://www.itu.int/itudoc/itu-t/rec/t/t_38am2.html 
>
>
>It is not there yet because it was bundled in an Amendment with T.38 Annex 
>E (H.248/Megaco) which was delayed... In the meantime, you can look at the 
>'draft' version and the IANA SDP registrations at: 
>ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/February00/ 
>
>
>Cheers, Glenn.


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  Tue Jul 25 02:30:35 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24817
	for ; Tue, 25 Jul 2000 02:30:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 303784433D; Tue, 25 Jul 2000 02:30:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 4069644338
	for ; Tue, 25 Jul 2000 02:29:58 -0400 (EDT)
Received: from dynamicsoft.com (1Cust63.tnt1.freehold.nj.da.uu.net [63.17.113.63])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09341;
	Tue, 25 Jul 2000 02:31:24 -0400 (EDT)
Message-ID: <397D34D8.5E88737F@dynamicsoft.com>
Date: Tue, 25 Jul 2000 02:34:00 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Yon 
Cc: Glenn Parsons , sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and T.38?
References: <4.3.2.7.2.20000724172644.00d12230@webhost.tactical-sw.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



David Yon wrote:
> 
>          I'm happy to see that "TCP" will become a registered name, but I
> don't see how the direction of the initial connection is negotiated.  I.e.,
> which side of the T.38 does the "connect" and which does the "accept"? 

I believe its the same as if it were UDP. If I receive an SDP message
with a UDP port for some stream, I send there upon receiving it; if
there is a TCP port for some stream, I open a connection there and send
on it. Receipt of SDP provides parameters to use in actively
communicating with a peer.

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 03:19:30 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08460
	for ; Tue, 25 Jul 2000 03:19:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 38A9C44351; Tue, 25 Jul 2000 03:19:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 2656644338
	for ; Tue, 25 Jul 2000 03:19:14 -0400 (EDT)
Received: from dynamicsoft.com (1Cust63.tnt1.freehold.nj.da.uu.net [63.17.113.63])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA09401;
	Tue, 25 Jul 2000 03:20:34 -0400 (EDT)
Message-ID: <397D405D.2486B34A@dynamicsoft.com>
Date: Tue, 25 Jul 2000 03:23:09 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dvir Oren 
Cc: SIP 
Subject: Re: [SIP] maddr and NATs
References: <14716.2357.177860.970744@jodie.lucid>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

The NAT issue is much more complex than this. See:
http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-firewalls-00.txt

-Jonathan R.

Dvir Oren wrote:
> 
> If a SIP entity adds an 'maddr' parameters, and that entity is
> behind a NAT, the address of the maddr will not work.  I'm assuming
> here that the SIP agent adds an IP address. There is also a problem
> when the client adds a Contact, and it is behind a NAT.
> 
> For Via fields - there is a received tag.  But for Contact, nobody will
> check that address.
> 
> It seems to me like there would be better chances passing a NAT if
> there were no Contacts.
> 
> --
> Dvir Oren               
> Lucid VON Ltd.     
> 9 Saloniki St.,        Tel-Aviv       Israel
> Tel:  +972 3 644 3038  Fax:  +972 3 644 3039
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 03:26:50 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10024
	for ; Tue, 25 Jul 2000 03:26:50 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5F86A4436E; Tue, 25 Jul 2000 03:26:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 6050D4434E
	for ; Tue, 25 Jul 2000 03:26:02 -0400 (EDT)
Received: from dynamicsoft.com (1Cust63.tnt1.freehold.nj.da.uu.net [63.17.113.63])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA09409
	for ; Tue, 25 Jul 2000 03:27:35 -0400 (EDT)
Message-ID: <397D4202.72EADA57@dynamicsoft.com>
Date: Tue, 25 Jul 2000 03:30:10 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] a reminder on list usage
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Folks,

I think it is time for another reminder on list usage guidelines.

The SIP wg mailing list is primarily to facilitate discussion around the
work items of the sip working group in IETF. Invariably, the list is
also the place where many people turn to for questions on SIP itself.
Thats OK, but time spent answering questions on the list is less time
advancing the working documents of the group. This time should be
minimized.

To that end, please, before you post your question, check the SIP FAQ:
http://www.cs.columbia.edu/~hgs/sip/faq/cache/1.html

and the list archives:
http://lists.bell-labs.com/pipermail/sip/

to see if your question has already been addressed. Only if you do not
find an answer there should you go to the list for your question. 

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 03:55:29 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16246
	for ; Tue, 25 Jul 2000 03:55:28 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 68ECA4434E; Tue, 25 Jul 2000 03:55:26 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 096A844338
	for ; Tue, 25 Jul 2000 03:55:21 -0400 (EDT)
Received: (qmail 31241 invoked by uid 1002); 25 Jul 2000 07:51:37 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 25 Jul 2000 10:51:35 +0300 (IDT)
To: Sunitha Kumar 
Cc: SIP 
Subject: [SIP] Question on Contact, and Route in the draft.
In-Reply-To: <397CA827.B1FAC243@vovida.com>
References: <397CA827.B1FAC243@vovida.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14717.17935.126.846794@jodie.lucid>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Sunitha Kumar writes ("[SIP] Question on Contact, and Route in the draft."):

> If this is the next request from the same end point, then the Route
> header list is

The problem only arrises on future requests.  On the first request,
each proxy will pass it on to the next proxy, until it reaches the
destination (adding Record-Route fields as necessary).  On the return
path (of the replies), the Via fields will be used.  Now, for sending
ACKs and BYEs, you will want to know to which proxies to send.  This
is done by changing Record-Route to Route.  The Contact field is
needed by the last proxy, to know to which destination it needs to
arrive to.

When the last proxy receives the ACK, the last Route field will be the 
value of the Contact field, which points to the desired destination.

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 05:13:16 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04808
	for ; Tue, 25 Jul 2000 05:13:16 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6629B44350; Tue, 25 Jul 2000 05:13:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from web1406.mail.yahoo.com (web1406.mail.yahoo.com [128.11.23.170])
	by lists.bell-labs.com (Postfix) with SMTP id 1E16444338
	for ; Tue, 25 Jul 2000 05:13:00 -0400 (EDT)
Received: (qmail 12517 invoked by uid 60001); 25 Jul 2000 09:12:59 -0000
Message-ID: <20000725091259.12516.qmail@web1406.mail.yahoo.com>
Received: from [192.245.102.12] by web1406.mail.yahoo.com; Tue, 25 Jul 2000 02:12:59 PDT
Date: Tue, 25 Jul 2000 02:12:59 -0700 (PDT)
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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,

My name is Niranjan and am working on Call Agent\MGC.
I would like to know more about the extensions being
added for SIP(for inter CA communication).

Also, I would like to know how different will the SIP
be when it's used for call signalling and inter CA\MGC
communication.

I don't understand why you need an extension for inter
CA\MGC communication.

Can anyone please clarify.


=====
With Regard's,
Niranjan.

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 06:14:42 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17987
	for ; Tue, 25 Jul 2000 06:14:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7D9404435B; Tue, 25 Jul 2000 06:14:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from june.idc1.level3.com (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 482C944338
	for ; Tue, 25 Jul 2000 06:14:20 -0400 (EDT)
Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140])
	by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id KAA16703;
	Tue, 25 Jul 2000 10:14:19 GMT
From: Aparna.Vemuri@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id EAA08549;
	Tue, 25 Jul 2000 04:14:19 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 25 Jul 2000 04:16:02 -0600
Message-ID: 
To: niranjandk@yahoo.com, sip@lists.bell-labs.com
Subject: RE: [SIP] SIP Clarification
Date: Tue, 25 Jul 2000 04:14:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Niranjan,
You may want to check out
http://search.ietf.org/internet-drafts/draft-vemuri-sip-t-context-00.txt

SIP-T is a mechanism that uses SIP to facilitate PSTN-IP inter-connections.
This document describes the architectures in which SIP-T may be used.

Thanks,
Aparna V.
Level (3) Communications.

-----Original Message-----
From: Niranjan Dhanakoti [mailto:niranjandk@yahoo.com]
Sent: Tuesday, July 25, 2000 3:13 AM
To: sip@lists.bell-labs.com
Subject: [SIP] SIP Clarification


Hi,

My name is Niranjan and am working on Call Agent\MGC.
I would like to know more about the extensions being
added for SIP(for inter CA communication).

Also, I would like to know how different will the SIP
be when it's used for call signalling and inter CA\MGC
communication.

I don't understand why you need an extension for inter
CA\MGC communication.

Can anyone please clarify.


=====
With Regard's,
Niranjan.

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/


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


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 08:51:00 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02907
	for ; Tue, 25 Jul 2000 08:51:00 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1911844368; Tue, 25 Jul 2000 08:50:42 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id B3FF444351
	for ; Tue, 25 Jul 2000 08:50:39 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA00545;
	Tue, 25 Jul 2000 08:50:38 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA02004;
	Tue, 25 Jul 2000 08:50:38 -0400 (EDT)
Message-ID: <397D8D1E.9BBECD7C@cs.columbia.edu>
Date: Tue, 25 Jul 2000 08:50:38 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: David Yon , Glenn Parsons ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and T.38?
References: <4.3.2.7.2.20000724172644.00d12230@webhost.tactical-sw.com> <397D34D8.5E88737F@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> David Yon wrote:
> >
> >          I'm happy to see that "TCP" will become a registered name, but I
> > don't see how the direction of the initial connection is negotiated.  I.e.,
> > which side of the T.38 does the "connect" and which does the "accept"?
> 
> I believe its the same as if it were UDP. If I receive an SDP message
> with a UDP port for some stream, I send there upon receiving it; if
> there is a TCP port for some stream, I open a connection there and send
> on it. Receipt of SDP provides parameters to use in actively
> communicating with a peer.

This would imply that either both sides open a (simplex) connection in
each direction (the most symmetric approach) or that the callee always
actively opens the connection if the caller includes SDP in the INVITE.
Alternatively, the caller could avoid putting SDP in the INVITE and wait
for the callee to do so, reversing the direction.

Given the likelihood that both caller and callee are behind a firewall,
it may not matter/help much to support fine-grained control.

-- 
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 Jul 25 09:04:52 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07897
	for ; Tue, 25 Jul 2000 09:04:52 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9FD794436A; Tue, 25 Jul 2000 09:04:40 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 730F44433F
	for ; Tue, 25 Jul 2000 09:04:36 -0400 (EDT)
Received: from fokus.gmd.de (dhcp007 [195.37.78.135])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA14984;
	Tue, 25 Jul 2000 15:03:46 +0200 (MET DST)
Message-ID: <397D7F87.CA160EA8@fokus.gmd.de>
Date: Tue, 25 Jul 2000 13:52:39 +0200
From: Jiri Kuthan 
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas 
Cc: Jonathan Rosenberg ,
        Howard Hart ,
        "Fairlie-Cuninghame, Robert" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Poorman's SIP through firewall.
References: 
		<3977D869.38F8AFD1@dynamicsoft.com>
		<39787974.99AC13E3@ipdialog.com>
		<397A9152.3946AC74@dynamicsoft.com> <14715.23407.572199.521488@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> Jonathan Rosenberg writes:
>  > Long term, we need solutions that allow network servers for specific
>  > applications (like SIP servers) to cooperate with firewalls to implement
>  > the overall network policy. This is the idea behind foglamps:
>  >
>  > http://search.ietf.org/internet-drafts/draft-kuthan-fcp-01.txt
> 
>    And when the e-2-e applications encrypt the
>    application payloads?

I do not think that what you are speaking about is a strictly technical
issue.  It is difficult to use firewalls and e2e encryption in 
the same way like it is difficult for a custom officer to do his 
job if he cannot inspect your luggage. If an administrator does 
deploy a firewall, it is not very likely he will allow arbitrary 
encrypted  traffic to get through it. If encryption is needed in 
firewall-ed networks to create VPNs, firewall-2-e seems to be the 
appropriate scenario rather than e-2-e.

> 
>    This entire thing strikes me as entirely
>    unsolvable: two colluding parties can always
>    defeat a net.marm. I saw an article on how
>    people were transmitting covert messages using
>    unused/mungable parts of IP and TCP headers.
>    The possibilities seem limitless.

Firewalls can hardly prevent communication of two
colluding parties. Their main value is they minimize
number of places vulnarable to external attacks.

Jiri



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


From sip-admin@lists.bell-labs.com  Tue Jul 25 09:36:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17210
	for ; Tue, 25 Jul 2000 09:36:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AC40244371; Tue, 25 Jul 2000 09:36:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 206144433F
	for ; Tue, 25 Jul 2000 09:36:19 -0400 (EDT)
Received: (qmail 330 invoked by uid 1002); 25 Jul 2000 13:32:34 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 25 Jul 2000 16:32:31 +0300 (IDT)
To: SIP 
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14717.38550.94398.991570@jodie.lucid>
Subject: [SIP] Using Request-URI
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Should a User-Agent assume that the Request-URI used to get to it
would be 'good enough' to be used in a Contact or Record-Route?  Or
should it somehow know of its own identity and use that at the risk of 
having an unreachable hostname?

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 10: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 ESMTP id KAA05341
	for ; Tue, 25 Jul 2000 10:30:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1EF1A44375; Tue, 25 Jul 2000 10:29:50 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hotmail.com (f296.law7.hotmail.com [216.33.236.174])
	by lists.bell-labs.com (Postfix) with SMTP id 2D4724433F
	for ; Tue, 25 Jul 2000 10:29:47 -0400 (EDT)
Received: (qmail 45856 invoked by uid 0); 25 Jul 2000 14:29:46 -0000
Message-ID: <20000725142946.45855.qmail@hotmail.com>
Received: from 164.164.6.34 by www.hotmail.com with HTTP;
	Tue, 25 Jul 2000 07:29:46 PDT
X-Originating-IP: [164.164.6.34]
From: "rahul pande" 
To: sip@lists.bell-labs.com
Date: Tue, 25 Jul 2000 14:29:46 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Subject: [SIP] some queries
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

hi all,
    i have some questions to ask :
1) what is the use to the Via header fields ?
2) In one of the articles i had read that "UDP enables SIP to multicast" 
does it mean that TCP cannot be used for this.
3) How do i issue multicast address, what is the mechanism?
4) if i want to send some text/plain message wiil i specify it like:
      m=text  tcp plain in SDP?
5) who is the registration server is it my location server or any other 
entity?
      I will reiterate that i am a novice and please convey to me the whole 
details even if the questions sound foolish.
     thanks,
          rahul

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.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 Jul 25 10:50:49 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12905
	for ; Tue, 25 Jul 2000 10:50:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0CB3944383; Tue, 25 Jul 2000 10:49:34 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 4A1914433F
	for ; Tue, 25 Jul 2000 10:49:21 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA27093; Tue, 25 Jul 2000 15:47:27 +0100 (BST)
From: "Jo Hornsby" 
To: 
Date: Tue, 25 Jul 2000 15:47:27 +0100
Message-ID: <000b01bff647$40971fa0$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] Clarification on 12.4 and non-INVITEs.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

May I humbly &:) suggest new wording for the paragraph on dealing
with 2xx responses in section 12.4:

From:
"The proxy MUST forward the response upstream towards the client,
 without sending an ACK down-stream."

To:
"If the request is an INVITE, the proxy MUST forward the response
 upstream, without sending an ACK downstream.  If the request is
 non-INVITE, the proxy should only forward the response upstream
 if it has not already forwarded a different (or similar) response."

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 Jul 25 10:53:21 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13937
	for ; Tue, 25 Jul 2000 10:53:21 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 86EBA4438C; Tue, 25 Jul 2000 10:49:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id DA0B344376
	for ; Tue, 25 Jul 2000 10:49:32 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA27097; Tue, 25 Jul 2000 15:47:37 +0100 (BST)
From: "Jo Hornsby" 
To: 
Date: Tue, 25 Jul 2000 15:47:37 +0100
Message-ID: <000c01bff647$4631e850$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] ACK handling at Stateful Proxies
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

I'd just like to clarify the following.  Section 12.3.5 says the
following:
"When an ACK request is received, it is either processed locally
 or proxied. To make this determination, the To, From, CSeq and
 Call-ID fields are compared against those in previous requests.
 If there is no match, the ACK request is proxied as if it were
 an INVITE request. If there is a match, and if the server had
 ever sent a 200 response upstream, the ACK is proxied. If the
 server had never sent any responses upstream, the ACK is also
 proxied. If the server had sent a 3xx, 4xx, 5xx or 6xx response,
 but no 2xx response, the ACK is processed locally if the tag in
 the To field of the ACK matches the tag sent by the proxy in
 the response."

Is it necessarily either/or?  According to the above paragraph, in
the case that a 200 arrives late, and the INVITE was not successful
(i.e., the proxy has already sent back a non-200), it will not
process the ACK locally (and thus will retransmit the response).

Might it be better as:
"...If there is a match, and if the server had never sent any
 responses upstream, or had sent 2xx responses upstream, the ACK
 is proxied.  Additionally, if the server had sent a 3xx, 4xx,
 5xx or 6xx response, the ACK is processed locally if the tag
 in the To field of the ACK matches the tag sent by the proxy in
 the response."


Going back to section 4.2.2:
"A proxy server receiving an ACK request after having sent a 3xx,
 4xx, 5xx, or 6xx response must make a determination about whether
 the ACK is for it, or for some user agent or proxy server further
 downstream.  This determination is made by examining the tag in
 the To field. If the tag in the ACK To header field matches the
 tag in the To header field of the response, and the From, CSeq
 and Call-ID header fields in the response match those in the ACK,
 the ACK is meant for the proxy server. Otherwise, the ACK SHOULD
 be proxied downstream as any other request."

This suffers from the same problem (if it is a problem), although
in this case, the proxy will also fail to do the right thing if
a 200 response to a re-INVITE arrives "late".

This doesn't cover all the cases (12.3.5 does), but instead of:
"Otherwise, the ACK SHOULD be proxied downstream as any other
 request."
perhaps:
"If the proxy had also forwarded at least one 2xx response, or
 if the tag or ACK is not meant for the proxy server, the ACK
 SHOULD be proxied downstream as any other request."

Finally, the indented paragraph in section 4.2.2:
"It is possible for a user agent client or proxy server to
 receive multiple 3xx, 4xx, 5xx, and 6xx responses to a request
 along a single branch. This can happen under various error
 conditions, typically when a forking proxy transitions from
 stateful to stateless before receiving all responses. The
 various responses will all be identical, except for the tag in
 the To field, which is different for each one. It can therefore
 be used as a means to disambiguate them. This method MUST be
 supported by SIP proxy, redirect and user agent servers as
 well as clients."

I'm slightly confused as to why this is here (I'm taking it
as some sort of explanation for the previous paragraph -- am I
being silly?), since it seems to be talking about client
behaviour rather than server behaviour.  I would say that
this is an important note of potential behaviour in itself, and
deserves to be far more prominent. &:)  Perhaps as a note
somewhere that a client needs to be prepared to receive more
than one final response, and should attempt to ACK them all,
using the tag in the To header to disambiguate?

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 Jul 25 10:55:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14772
	for ; Tue, 25 Jul 2000 10:55:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7A23544397; Tue, 25 Jul 2000 10:50:21 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 2CE1344392
	for ; Tue, 25 Jul 2000 10:50:18 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0FY900D01D6LEM@firewall.mcit.com> for sip@lists.bell-labs.com; Tue,
 25 Jul 2000 14:49:33 +0000 (GMT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FY90079FD6KRH@firewall.mcit.com>; Tue,
 25 Jul 2000 14:49:33 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 id <0FY900I01D6K1B@dgismtp01.wcomnet.com>; Tue,
 25 Jul 2000 14:49:32 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0FY900I01D6H09@dgismtp01.wcomnet.com>;
 Tue, 25 Jul 2000 14:49:32 +0000 (GMT)
Received: from C25776A ([166.46.20.188])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0FY900H61D60IG@dgismtp01.wcomnet.com>; Tue,
 25 Jul 2000 14:49:16 +0000 (GMT)
Date: Tue, 25 Jul 2000 09:49:05 -0500
From: Henry Sinnreich 
To: aaa-wg@merit.edu, sip@lists.bell-labs.com
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Subject: [SIP] SIP AAA and QoS drafts
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Three I-D's are related to both the SIP WG and the AAAarch RG:


is a new draft within the scope of the SIP WG
http://www.softarmor.com/sipwg/drafts/draft-johnston-sip-osp-tok
en-00.txt

Abstract

   This draft proposes a new SIP (Session Initiation Protocol)
header
   OSP-Authorization-Token for carrying an OSP (Open Settlements
   Protocol) authorization token between domains.


gives the framework for the above,
http://www.softarmor.com/sipwg/drafts/draft-sinnreich-sip-qos-os
p-01.txt

Abstract

   Commercial grade IP telephony requires linkage between call
setup,
   end-to-end QoS setup, interdomain authorization and
accounting. This
   draft considers the network model for inter-domain QoS for
access and
   transit networks, the service models and policy
implementation
   options. Also, interdomain authorization and accounting may
require
   the trust services of a clearinghouse, to which the local
policy
   server may outsource authorization for support for
inter-domain
   accounting.

   The draft defines two options for QoS support for telephony:
PSTN-
   style "QoS Assured" or Internet-style "QoS Enabled" service.
   Implementing the local policy or QoS deployment can also have
two
   options: The more usual policy "Pull Model" and the policy
"Push
   Model" that may be advantageous for large IP telephony
gateway
   deployments. The draft illustrates the various combinations
of QoS
   service and policy implementation for interdomain QoS with
   authorization and accounting.

   The inter-process communications between the SIP, SDP, RSVP
and OSP
   protocol engines is illustrated. Future work for SIP/SDP and
other
   extensions, QoS metric and policy is outlined to make
interdomain QoS
   for IP telephony possible.

 and


is for the AAAarch RG.
http://www.softarmor.com/sipwg/drafts/draft-sinnreich-aaa-interd
omain-sip-qos-osp-00.txt


Abstract

   This draft specifies the AAA functions and message exchanges
for
   interdomain SIP telephony call setup with QoS. Usage
accounting is
   provided with clearing house support using the Open
Settlement
   Protocol.  Interdomain message exchanges use existing IETF
protocols.

   The use of existing protocols is however modeled in the
proposed AAA
   Architecture of the IETF AAAArch RG [1]. Though the approach
has been
   developed specifically for IP telephony, using the AAA
Architecture
   may allow a future AAA protocol to go beyond IP telephony to
serve
   alike for other applications.

The drafts will be published in the IETF archive and can be
found at present at

http://www.softarmor.com/sipwg/drafts/

Thanks, Henry

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



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


From sip-admin@lists.bell-labs.com  Tue Jul 25 10:58:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15846
	for ; Tue, 25 Jul 2000 10:58:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5EDAE4439F; Tue, 25 Jul 2000 10:54:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by lists.bell-labs.com (Postfix) with ESMTP id 3D94544392
	for ; Tue, 25 Jul 2000 10:54:40 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15696;
	Tue, 25 Jul 2000 08:54:12 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA14509;
	Tue, 25 Jul 2000 07:54:11 -0700 (PDT)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA22724;
	Tue, 25 Jul 2000 07:54:10 -0700 (PDT)
Date: Tue, 25 Jul 2000 07:53:10 -0700 (PDT)
From: "pcalhoun@eng.sun.com" 
Reply-To: "pcalhoun@eng.sun.com" 
To: Henry Sinnreich 
Cc: aaa-wg@merit.edu, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Subject: [SIP] Re: SIP AAA and QoS drafts
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

> 
> 
> is for the AAAarch RG.
> http://www.softarmor.com/sipwg/drafts/draft-sinnreich-aaa-interd
> omain-sip-qos-osp-00.txt
> 
Henry,

The above implies that AAAarch RG has adopted OSP as their protocol. Is this
correct, or are you proposing OSP in that WG? I am sorry if I am a little out
of touch with the AAARG, but my cellular related activies pretty much deny
me from the joys to working on a third AAA protocol :) :)



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


From sip-admin@lists.bell-labs.com  Tue Jul 25 11: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 ESMTP id LAA24361
	for ; Tue, 25 Jul 2000 11:21:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0CBA844383; Tue, 25 Jul 2000 11:20:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 2B12B44369
	for ; Tue, 25 Jul 2000 11:20:46 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256)
 id <0FY900M01EMGNE@firewall.mcit.com> for sip@lists.bell-labs.com; Tue,
 25 Jul 2000 15:20:40 +0000 (GMT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FY900M0AEMGN2@firewall.mcit.com>; Tue,
 25 Jul 2000 15:20:40 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 id <0FY900601EMGCN@dgismtp01.wcomnet.com>; Tue,
 25 Jul 2000 15:20:40 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0FY900601EMBB4@dgismtp01.wcomnet.com>;
 Tue, 25 Jul 2000 15:20:40 +0000 (GMT)
Received: from C25776A ([166.46.20.188])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0FY9003IJELTWL@dgismtp01.wcomnet.com>; Tue,
 25 Jul 2000 15:20:18 +0000 (GMT)
Date: Tue, 25 Jul 2000 10:20:08 -0500
From: Henry Sinnreich 
Subject: RE: [SIP] Re: SIP AAA and QoS drafts
In-reply-to: 
To: "pcalhoun@eng.sun.com" 
Cc: aaa-wg@merit.edu, sip@lists.bell-labs.com
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

>The above implies that AAAarch RG has adopted OSP as
>their protocol.

Pat,

This is not the case. Sorry if there is a miscommunication, we
have not said so in the draft. We said this is an illustration
using existing protocols, as a possible input for a future AAA
protocol.

Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>pcalhoun@eng.sun.com
>Sent: Tuesday, July 25, 2000 9:53 AM
>To: Henry Sinnreich
>Cc: aaa-wg@merit.edu; sip@lists.bell-labs.com
>Subject: [SIP] Re: SIP AAA and QoS drafts
>
>
>>
>> 
>> is for the AAAarch RG.
>>
>http://www.softarmor.com/sipwg/drafts/draft-sinnreich-a
>aa-interd
>> omain-sip-qos-osp-00.txt
>>
>Henry,
>
>The above implies that AAAarch RG has adopted OSP as
>their protocol. Is this
>correct, or are you proposing OSP in that WG? I am
>sorry if I am a little out
>of touch with the AAARG, but my cellular related
>activies pretty much deny
>me from the joys to working on a third AAA protocol :) :)
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/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 Jul 25 11: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 ESMTP id LAA00824
	for ; Tue, 25 Jul 2000 11:39:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A978F44372; Tue, 25 Jul 2000 11:39:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id A88564436A
	for ; Tue, 25 Jul 2000 11:38:42 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id QAA00709; Tue, 25 Jul 2000 16:36:29 +0100 (BST)
From: "Jo Hornsby" 
To: 
Date: Tue, 25 Jul 2000 16:36:28 +0100
Message-ID: <001001bff64e$19c535e0$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] Late Loop Detection
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi again,

I am reraising this in the hope that it can be resolved without
becoming an "OPEN ISSUE" (I really don't feel it's that significant,
as a question, but I do feel it needs answering).

I use the term "late" here to indicate that an upstream stateful
proxy did not detect a loop, and thus ended up sending a request
downstream "twice".

If a proxy detects a looped request, should it always respond with
482, even if it knows it will not be able to distinguish between
an ACK/CANCEL for the "legal leg" of the request and the "looped leg"
of the request?  This is also undesirable because it can confuse
the proxy where the request really looped from thinking that a
a transaction has completed when it has not.

The best "solution" (that I can come up with, anyway), is to
recommend that proxies create branch parameters in their Vias,
which somehow have a unique component, such that any proxy
would be able to recognise if it had generated a Via just by
looking at the branch parameter.  This way, proxies can easily
do loop detection just by looking at the branch parameter in
Vias.  Of course, this doesn't really help a proxy if it does
detect a loop "late", but it should prevent the most likely
scenario where this occurs (when Via hiding is employed).

For a more verbose and even less interesting discussion, have
at my post(s?) in the thread "[SIP] hiding via field and loop
detection" from sometime last week.

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 Jul 25 11:45:25 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02772
	for ; Tue, 25 Jul 2000 11:45:24 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6E5DC44382; Tue, 25 Jul 2000 11:45:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 1A18F4433F
	for ; Tue, 25 Jul 2000 11:45:14 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id QAA01426; Tue, 25 Jul 2000 16:42:50 +0100 (BST)
From: "Jo Hornsby" 
To: "Dvir Oren" , "SIP" 
Subject: RE: [SIP] Using Request-URI
Date: Tue, 25 Jul 2000 16:42:50 +0100
Message-ID: <001101bff64e$fcfcef60$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <14717.38550.94398.991570@jodie.lucid>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> Should a User-Agent assume that the Request-URI used to get to it
> would be 'good enough' to be used in a Contact or Record-Route?  Or
> should it somehow know of its own identity and use that at the risk of 
> having an unreachable hostname?

In my arrogance, I would consider a User-Agent that didn't know
its own Contact address to be slightly poor.

If you're trying to legislate against NATs screwing things up,
as Jonathan has already pointed out, Contact is just the Tip
of the Iceberg.  A UA needs a lot more help; from a proxy
talking to an ALG, for example.


 - 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 Jul 25 11:48:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03691
	for ; Tue, 25 Jul 2000 11:48:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EB20A4439B; Tue, 25 Jul 2000 11:46:18 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ss3000e.cselt.it (ss3000e.cselt.it [163.162.41.5])
	by lists.bell-labs.com (Postfix) with ESMTP id C3F0044397
	for ; Tue, 25 Jul 2000 11:46:15 -0400 (EDT)
Received: from grizzly.cselt.it (grizzly.cselt.it [163.162.17.207])
 by ss3000e.cselt.it (PMDF V5.2-31 #43137)
 with ESMTP id <0FY90019HFINXU@ss3000e.cselt.it> for sip@lists.bell-labs.com;
 Tue, 25 Jul 2000 17:39:59 +0200 (MET DST)
Received: from athena.polito.it (hpi7225.cselt.it [163.162.217.51])
	by grizzly.cselt.it (8.8.8+Sun/8.8.8) with ESMTP id RAA28764	for
 ; Tue, 25 Jul 2000 17:41:01 +0200 (MET DST)
Date: Tue, 25 Jul 2000 17:43:59 +0200
From: Laurent-Walter Goix 
Subject: [SIP] Third-party registration
To: sip@lists.bell-labs.com
Message-id: <397DB5BF.85EC7E57@athena.polito.it>
Organization: Politecnico di Torino / INSA de Lyon
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
Content-type: multipart/mixed; boundary="------------A737419AB02028B969466D4A"
X-Accept-Language: en
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

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

I need some clarification about some security considerations in
third-party registration that I haven't found in the archive. I maybe
miss them...

Draft rfc2543bis shows in section 16.1 an example of a third-party
registration with the secretary registering his boss. Section 4.2.6
specifies From header as the "address-of-record of the person
responsible for the registration".

Now my doubts:
- As one can understand, and as I haven't found any security
consideration about it, there is only one person who can be responsible
for a certain "address-of-record" (her own or anyone else). Is the
security check performed at the registrar depending on its
implementation or is there some standard specification? To reuse the
example, can the boss registers itself (I would be quite logical...) or
only his secretary can do it since she is responsible for his
registration?

- Then if someone can register someone else's address, is there any
authentication check performed by the registrar based on a
"responsible-for-M.X" addresses list in some database or even after some
authentication process (based on the From header) ?

Authentication header is only optional in REGISTER requests, but why
isn't it mandatory in case of some third-party registration request to
avoid misbehaviours (or shouldn't the server automatically responds a
401 Unauthorized when the header wasn't found)?

Thanks,

Laurent-Walter Goix

--------------A737419AB02028B969466D4A
Content-Type: text/x-vcard; charset=us-ascii;
 name="goix.vcf"
Content-Description: Card for Laurent-Walter Goix
Content-Disposition: attachment;
 filename="goix.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Goix;Laurent-Walter
tel;cell:+393483939834
x-mozilla-html:FALSE
org:Politecnico di Torino / INSA de Lyon;Telecommunications engineering
adr:;;;;;;
version:2.1
email;internet:goix@athena.polito.it
title:5th year Erasmus student
fn:Goix, Laurent-Walter
end:vcard

--------------A737419AB02028B969466D4A--



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


From sip-admin@lists.bell-labs.com  Tue Jul 25 12:41:29 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22190
	for ; Tue, 25 Jul 2000 12:41:28 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 381E84436A; Tue, 25 Jul 2000 12:41:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 3720644338
	for ; Tue, 25 Jul 2000 12:41:07 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA12327;
	Tue, 25 Jul 2000 12:42:31 -0400 (EDT)
Message-ID: <397DC415.86C66CE9@dynamicsoft.com>
Date: Tue, 25 Jul 2000 12:45:09 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Laurent-Walter Goix 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Third-party registration
References: <397DB5BF.85EC7E57@athena.polito.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Laurent-Walter Goix wrote:
> 
> I need some clarification about some security considerations in
> third-party registration that I haven't found in the archive. I maybe
> miss them...
> 
> Draft rfc2543bis shows in section 16.1 an example of a third-party
> registration with the secretary registering his boss. Section 4.2.6
> specifies From header as the "address-of-record of the person
> responsible for the registration".
> 
> Now my doubts:
> - As one can understand, and as I haven't found any security
> consideration about it, there is only one person who can be responsible
> for a certain "address-of-record" (her own or anyone else).

No. Any number of people can send a third party registration. In the
example, the secretary, the boss, and the boss's husband could all send
registrations for the boss (i.e., the To field in all these contains
sip:boss@example.com).

> Is the
> security check performed at the registrar depending on its
> implementation or is there some standard specification? To reuse the
> example, can the boss registers itself (I would be quite logical...) or
> only his secretary can do it since she is responsible for his
> registration?

Authorization policy is your own decision. If your service wishes to
restrict people to only register themselves, thats your decision.


> 
> - Then if someone can register someone else's address, is there any
> authentication check performed by the registrar based on a
> "responsible-for-M.X" addresses list in some database or even after some
> authentication process (based on the From header) ?

Don't confuse authentication and authorizaiton. Authentication is "who
are you", authorization is "can you do X". You would authenticate a
REGISTER as coming from the user in the From field. Once authenticated
(yes, this is the secretary), the authorization decision tells you
whether this person can perform the desired action. The authorization
decision can be arbitrarily complex and is a matter of policy.

> 
> Authentication header is only optional in REGISTER requests, but why
> isn't it mandatory in case of some third-party registration request to
> avoid misbehaviours (or shouldn't the server automatically responds a
> 401 Unauthorized when the header wasn't found)?

If your servers authorization policy is to allow anyone to register for
anyone else, you don't need to authenticate the requests. Thus, whether
you use/need authentication is at the discretion of the administrator.

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


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 15:26:24 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09551
	for ; Tue, 25 Jul 2000 15:26:24 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ACDF64436A; Tue, 25 Jul 2000 15:26:20 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 65CBD44338
	for ; Tue, 25 Jul 2000 15:26:05 -0400 (EDT)
Received: (qmail 1727 invoked by uid 1002); 25 Jul 2000 19:22:12 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 25 Jul 2000 22:22:09 +0300 (IDT)
To: "Jo Hornsby" 
Cc: SIP 
Subject: RE: [SIP] Using Request-URI
In-Reply-To: <001101bff64e$fcfcef60$4e34c3c1@ubiquity.co.uk>
References: <14717.38550.94398.991570@jodie.lucid>
	<001101bff64e$fcfcef60$4e34c3c1@ubiquity.co.uk>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14717.59385.431537.899170@jodie.lucid>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jo Hornsby writes ("RE: [SIP] Using Request-URI"):

> In my arrogance, I would consider a User-Agent that didn't know
> its own Contact address to be slightly poor.

This is not the point.  How I know myself may not be the same as how
my proxy knows me.

I may have a machine with a hostname that cannot be found in the DNS.
If my SIP UA will decide to put a Contact field based on a
gethostbyname(), for example, it will assist no one since my host name 
is not a valid hostname.

However, my proxy can reach me through some hostname that is valid and 
that the proxy knows it, but I don't, for some reason.

This is why I thought of using the Request-URI instead of trying to
figure out my own Contact, which may lead me to results that my proxy
can't handle.

It seems to me that if the Request-URI got to me, using it as a
Contact field will also get to me.

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 15:36:37 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12929
	for ; Tue, 25 Jul 2000 15:36:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 55AD844387; Tue, 25 Jul 2000 15:35:35 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by lists.bell-labs.com (Postfix) with ESMTP id 94E9444377
	for ; Tue, 25 Jul 2000 15:35:31 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26622;
	Tue, 25 Jul 2000 13:35:28 -0600 (MDT)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA18172;
	Tue, 25 Jul 2000 12:35:22 -0700 (PDT)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA11057;
	Tue, 25 Jul 2000 12:35:22 -0700 (PDT)
Date: Tue, 25 Jul 2000 12:34:20 -0700 (PDT)
From: "pcalhoun@eng.sun.com" 
Reply-To: "pcalhoun@eng.sun.com" 
Subject: RE: [SIP] Re: SIP AAA and QoS drafts
To: Henry Sinnreich 
Cc: "pcalhoun@eng.sun.com" , aaa-wg@merit.edu,
        sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

> >The above implies that AAAarch RG has adopted OSP as
> >their protocol.
> 
> Pat,
> 
> This is not the case. Sorry if there is a miscommunication, we
> have not said so in the draft. We said this is an illustration
> using existing protocols, as a possible input for a future AAA
> protocol.

check. Thanks for the response.

PatC



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


From sip-admin@lists.bell-labs.com  Tue Jul 25 16:36:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28472
	for ; Tue, 25 Jul 2000 16:36:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3611744383; Tue, 25 Jul 2000 16:35:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251])
	by lists.bell-labs.com (Postfix) with ESMTP id 44FC344338
	for ; Tue, 25 Jul 2000 16:35:35 -0400 (EDT)
Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com
 (Rockliffe SMTPRA 3.4.2) with SMTP id ;
 Tue, 25 Jul 2000 13:34:16 -0700
From: "Simon Barber" 
To: 
Cc: "Jonathan Rosenberg" 
Subject: RE: [SIP] SIP and T.38?
Date: Tue, 25 Jul 2000 13:35:48 -0700
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.00.2919.6700
In-Reply-To: <397D34D8.5E88737F@dynamicsoft.com>
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

JR wrote:
> David Yon wrote:
> >          I'm happy to see that "TCP" will become a registered name, but
I
> > don't see how the direction of the initial connection is negotiated.
I.e.,
> > which side of the T.38 does the "connect" and which does the "accept"?
>
> I believe its the same as if it were UDP. If I receive an SDP message
> with a UDP port for some stream, I send there upon receiving it; if

TCP has an important difference from UDP, that a connection must be
originated from one end, and accepted at the other, but then data is
exchanged 2 ways. RTP connections are explicitly one way, and do not have
this directional creation. Bi directional data transfer with RTP is
accomplished by having 2 separate connections (one in each direction). These
might share UDP port numbers, but they are 2 separate connections.

More specifically:

for an RTP connection the receiver of data opens a specific UDP port number
on which to receive RTP packets. The RTP connection is defined by the
specific port number and IP address tuple of the receiver (please correct me
if I'm wrong - this is from memory). The sender then sends data (from any IP
address or port) to this receiver. Multiple talkers in a conference are
distinguished by different SSRCs. These can be received BOTH in multicast
mode AND in unicast mode. (does anyone have any idea if any SIP UAs support
multiple SSRCs at the moment?)

For a TCP connection the connection is opened in a specific direction, but
is then 2 way (data exchange can happen in either, or both directions). The
connection is defined by the 4 tuple of sender address and port, and
receiver address and port. A second backwards connection cannot be opened
with the same address/port numbers as the original connection.

This leaves the issue for TCP connections of deciding in advance who will
initiate the connection, (connect) and who will accept it. In a world
without firewalls one could imagine using a random number generated on both
sides, the side generating the higher number opening the connection (say).
Unfortunately firewalls may impose a requirement that a particular client
can only open an outbound connection - and cannot be the accepting end. In
this case the client must make the connections.

The problem scenario is where both clients must make the outbound
connection, and neither can accept a connection (say both are bahind
firewalls that only let out TCP connections). In this case the only solution
is for a third party to accept both connections and bridge the connections
together.

Simon Barber


-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg
Sent: Monday, July 24, 2000 11:34 PM
To: David Yon
Cc: Glenn Parsons; sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and T.38?




David Yon wrote:
>
>          I'm happy to see that "TCP" will become a registered name, but I
> don't see how the direction of the initial connection is negotiated.
I.e.,
> which side of the T.38 does the "connect" and which does the "accept"?

I believe its the same as if it were UDP. If I receive an SDP message
with a UDP port for some stream, I send there upon receiving it; if
there is a TCP port for some stream, I open a connection there and send
on it. Receipt of SDP provides parameters to use in actively
communicating with a peer.

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


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



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


From sip-admin@lists.bell-labs.com  Tue Jul 25 16:56:50 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04700
	for ; Tue, 25 Jul 2000 16:56:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 831644436A; Tue, 25 Jul 2000 16:56:47 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by lists.bell-labs.com (Postfix) with SMTP id F297844338
	for ; Tue, 25 Jul 2000 16:56:43 -0400 (EDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Jul 2000 13:54:53 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58)
	id ; Tue, 25 Jul 2000 13:54:21 -0700
Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C31E9@red-msg-24.redmond.corp.microsoft.com>
From: Christian Huitema 
To: "'Jiri Kuthan'" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Poorman's SIP through firewall.
Date: Tue, 25 Jul 2000 13:54:38 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Jiri,

In one sentence you said:

> ... If an administrator does 
> deploy a firewall, it is not very likely he will allow arbitrary 
> encrypted  traffic to get through it. 

but, a few line later, you wrote:

> Firewalls can hardly prevent communication of two
> colluding parties. Their main value is they minimize
> number of places vulnarable to external attacks.

Don't you see that there is some form of contradiction here? Preventing
e-2-e encryption is a rather dubious way of minimizing the number of places
vulnerable to attack. It has more to do with enforcement of policies. But at
some level, firewall administrators have to trust their users. A blanket ban
on encryption is futile.

End-to-end encryption, in fact, is commonly used between web clients and
servers, with SSL, and most firewalls let that go through -- they would
rather tolerate encryption than force credit card numbers to be carried in
clear text. The equivalent would be the encryption of the RTP payload while
leaving the UDP headers unencrypted; I would certainly expect that to go
through many firewalls.


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 16:58:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05142
	for ; Tue, 25 Jul 2000 16:58:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D65444439B; Tue, 25 Jul 2000 16:58:37 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id D86A94438F
	for ; Tue, 25 Jul 2000 16:58:34 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id QAA96612; Tue, 25 Jul 2000 16:58:34 -0400 (EDT)
Message-ID: <09f001bff67b$a0b65f20$3102a8c0@broadsoft.com>
From: "Brett Tate" 
To: "SIPbell-labs" 
Date: Tue, 25 Jul 2000 17:02:22 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_09ED_01BFF65A.197B6530"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] rfc2543bis: table 4 comments
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_09ED_01BFF65A.197B6530
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The following are comments for section 6 table 4 of rfc2543bis.

Row "Contact R" column "INV" should be "m".

Row "Contact 2xx" column "INV" should be "m".

Row "Content-Language" should be all "o" instead of "m".

Row "Content-Length" should be all "o" if the last two=20
paragraphs in section 6.19 are correct.


Please reply if these comments are not correct.

------=_NextPart_000_09ED_01BFF65A.197B6530
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









The following are comments for section 6 table 4 of=20
rfc2543bis.


 


Row "Contact R" column "INV" should be =
"m".


 


Row "Contact 2xx" column "INV" should be =
"m".


 


Row "Content-Language" should be all "o" instead of=20
"m".


 


Row "Content-Length" should be all "o" if the last =
two=20



paragraphs in section 6.19 are correct.


 


 


Please reply if these comments are not=20
correct.


------=_NextPart_000_09ED_01BFF65A.197B6530--



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


From sip-admin@lists.bell-labs.com  Tue Jul 25 18:08:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23580
	for ; Tue, 25 Jul 2000 18:08:48 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0A2094437C; Tue, 25 Jul 2000 18:08:18 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id BFB8D44338
	for ; Tue, 25 Jul 2000 18:08:15 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA12953;
	Tue, 25 Jul 2000 18:08:14 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA13117;
	Tue, 25 Jul 2000 18:08:14 -0400 (EDT)
Message-ID: <397E0FCE.5D807D95@cs.columbia.edu>
Date: Tue, 25 Jul 2000 18:08:14 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Brett Tate 
Cc: SIPbell-labs 
Subject: Re: [SIP] rfc2543bis: table 4 comments
References: <09f001bff67b$a0b65f20$3102a8c0@broadsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> Brett Tate wrote:
> 
> The following are comments for section 6 table 4 of rfc2543bis.
> 
> Row "Contact R" column "INV" should be "m".
> 
> Row "Contact 2xx" column "INV" should be "m".
> 
> Row "Content-Language" should be all "o" instead of "m".

Fixed - thanks.

> 
> Row "Content-Length" should be all "o" if the last two
> paragraphs in section 6.19 are correct.

It says "SHOULD" for Content-Length, so this is probably closer to 'm'
than 'o'.

> 
> 
> Please reply if these comments are not correct.

-- 
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 Jul 25 18: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 ESMTP id SAA04964
	for ; Tue, 25 Jul 2000 18:39:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9301944390; Tue, 25 Jul 2000 18:39:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 7EAB344338
	for ; Tue, 25 Jul 2000 18:39:35 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA14309;
	Tue, 25 Jul 2000 18:39:35 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA13613;
	Tue, 25 Jul 2000 18:39:34 -0400 (EDT)
Message-ID: <397E1726.5ADA57DD@cs.columbia.edu>
Date: Tue, 25 Jul 2000 18:39:34 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jo Hornsby 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] ACK handling at Stateful Proxies
References: <000c01bff647$4631e850$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jo Hornsby wrote:
> 
> Hi,
> 
> I'd just like to clarify the following.  Section 12.3.5 says the
> following:
> "When an ACK request is received, it is either processed locally
>  or proxied. To make this determination, the To, From, CSeq and
>  Call-ID fields are compared against those in previous requests.
>  If there is no match, the ACK request is proxied as if it were
>  an INVITE request. If there is a match, and if the server had
>  ever sent a 200 response upstream, the ACK is proxied. If the
>  server had never sent any responses upstream, the ACK is also
>  proxied. If the server had sent a 3xx, 4xx, 5xx or 6xx response,
>  but no 2xx response, the ACK is processed locally if the tag in
>  the To field of the ACK matches the tag sent by the proxy in
>  the response."
> 
> Is it necessarily either/or?  According to the above paragraph, in
> the case that a 200 arrives late, and the INVITE was not successful
> (i.e., the proxy has already sent back a non-200), it will not
> process the ACK locally (and thus will retransmit the response).

Not sure I get the scenario, but here's my interpretation:

- proxy times out branch (and sends CANCEL)
- proxy sends some 4/5/6xx upstream
- 200 arrives from the timed-out branch since it met the CANCEL in
mid-flight
- proxy forwards 200 upstream
- UA ACKs both 4/5/6 and 200, as appropriate


> 
> Going back to section 4.2.2:
> "A proxy server receiving an ACK request after having sent a 3xx,
>  4xx, 5xx, or 6xx response must make a determination about whether
>  the ACK is for it, or for some user agent or proxy server further
>  downstream.  This determination is made by examining the tag in
>  the To field. If the tag in the ACK To header field matches the
>  tag in the To header field of the response, and the From, CSeq
>  and Call-ID header fields in the response match those in the ACK,
>  the ACK is meant for the proxy server. Otherwise, the ACK SHOULD
>  be proxied downstream as any other request."
> 
> This suffers from the same problem (if it is a problem), although
> in this case, the proxy will also fail to do the right thing if
> a 200 response to a re-INVITE arrives "late".
> 
> This doesn't cover all the cases (12.3.5 does), but instead of:
> "Otherwise, the ACK SHOULD be proxied downstream as any other
>  request."
> perhaps:
> "If the proxy had also forwarded at least one 2xx response, or
>  if the tag or ACK is not meant for the proxy server, the ACK
>  SHOULD be proxied downstream as any other request."
> 
> Finally, the indented paragraph in section 4.2.2:
> "It is possible for a user agent client or proxy server to
>  receive multiple 3xx, 4xx, 5xx, and 6xx responses to a request
>  along a single branch. This can happen under various error
>  conditions, typically when a forking proxy transitions from
>  stateful to stateless before receiving all responses. The
>  various responses will all be identical, except for the tag in
>  the To field, which is different for each one. It can therefore
>  be used as a means to disambiguate them. This method MUST be
>  supported by SIP proxy, redirect and user agent servers as
>  well as clients."
> 
> I'm slightly confused as to why this is here (I'm taking it
> as some sort of explanation for the previous paragraph -- am I
> being silly?), since it seems to be talking about client
> behaviour rather than server behaviour.  I would say that
> this is an important note of potential behaviour in itself, and
> deserves to be far more prominent. &:)  Perhaps as a note
> somewhere that a client needs to be prepared to receive more
> than one final response, and should attempt to ACK them all,
> using the tag in the To header to disambiguate?

The user agent section already has:

Multiple responses may arrive at the UAC for a single {\INVITE} request,
due to a forking proxy.  Each response is distinguished by the
``\header{tag}'' parameter in the \header{To} header field, and each
represents a distinct call leg.  The caller {\MAY} choose to acknowledge
or terminate the call with each responding UAS.

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 Jul 25 18:41:58 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05771
	for ; Tue, 25 Jul 2000 18:41:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1F093443A0; Tue, 25 Jul 2000 18:41:56 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id B2E9E44383
	for ; Tue, 25 Jul 2000 18:41:52 -0400 (EDT)
Received: from fokus.gmd.de (dhcp007 [195.37.78.135])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA02120;
	Wed, 26 Jul 2000 00:41:49 +0200 (MET DST)
Message-ID: <397E178C.FD57CEE2@fokus.gmd.de>
Date: Wed, 26 Jul 2000 00:41:16 +0200
From: Jiri Kuthan 
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Poorman's SIP through firewall.
References: <2E3FA0558747934A8F753CC533A3F6DF043C31E9@red-msg-24.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Christian Huitema wrote:
> 
> Jiri,
> 
> In one sentence you said:
> 
> > ... If an administrator does
> > deploy a firewall, it is not very likely he will allow arbitrary
> > encrypted  traffic to get through it.
> 
> but, a few line later, you wrote:
> 
> > Firewalls can hardly prevent communication of two
> > colluding parties. Their main value is they minimize
> > number of places vulnarable to external attacks.
> 
> Don't you see that there is some form of contradiction here? Preventing
> e-2-e encryption is a rather dubious way of minimizing the number of places
> vulnerable to attack. It has more to do with enforcement of policies. But at
> some level, firewall administrators have to trust their users. A blanket ban
> on encryption is futile.
> 
> End-to-end encryption, in fact, is commonly used between web clients and
> servers, with SSL, and most firewalls let that go through -- they would
> rather tolerate encryption than force credit card numbers to be carried in
> clear text. The equivalent would be the encryption of the RTP payload while
> leaving the UDP headers unencrypted; I would certainly expect that to go
> through many firewalls.

Christian,

sorry, I was not precise about problem definition. I've been refering to particular
SIP/SDP/RTP/default-deny-firewall scenarios where packet filtering
at IP+UDP/TCP level cannot be applied to media streams because either
a) RTP streams are encrypted at IP level 
 or
b) SDP is encrypted (in which case a session will not get through firewalls
   because they do not see SDP payload and cannot generate dynamic
   pinholes for media belonging to sessions considered trustworthy)

I agree that if SDP is not encrypted and RTP packets are encrypted at RTP 
level, firewalls still may enforce reasonable packet-filtering policies
and minimize the number of vulnerable places. The same
holds for HTTP/SSL where port numbers are visible and the protocol
does not use session bundling.

Jiri


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


From sip-admin@lists.bell-labs.com  Tue Jul 25 19:51:40 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26730
	for ; Tue, 25 Jul 2000 19:51:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A3D4F44390; Tue, 25 Jul 2000 19:51:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 1079144338
	for ; Tue, 25 Jul 2000 19:51:01 -0400 (EDT)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA03870;
	Tue, 25 Jul 2000 16:51:16 -0700 (PDT)
Received: from sony-laptop ([171.68.213.144])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAB54845;
	Tue, 25 Jul 2000 16:50:51 -0700 (PDT)
Message-Id: <4.1.20000725164334.00abc510@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 25 Jul 2000 16:52:32 +0200
To: Dvir Oren , "Jo Hornsby" 
From: Rohan Mahy 
Subject: RE: [SIP] Using Request-URI
Cc: SIP 
In-Reply-To: <14717.59385.431537.899170@jodie.lucid>
References: <001101bff64e$fcfcef60$4e34c3c1@ubiquity.co.uk>
 <14717.38550.94398.991570@jodie.lucid>
 <001101bff64e$fcfcef60$4e34c3c1@ubiquity.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

At 09:22 PM 7/25/00 , Dvir Oren wrote:
>Jo Hornsby writes ("RE: [SIP] Using Request-URI"):
>
>> In my arrogance, I would consider a User-Agent that didn't know
>> its own Contact address to be slightly poor.
>
>This is not the point.  How I know myself may not be the same as how
>my proxy knows me.
>
>I may have a machine with a hostname that cannot be found in the DNS.
>If my SIP UA will decide to put a Contact field based on a
>gethostbyname(), for example, it will assist no one since my host name 
>is not a valid hostname.
>
>However, my proxy can reach me through some hostname that is valid and 
>that the proxy knows it, but I don't, for some reason.

It seems reasonable to check your own "hostname" in DNS before you give it
out to someone else.  If it doesn't resolve, just use your IP address in
Contact.

	Contact: 

thanks,
-rohan

>This is why I thought of using the Request-URI instead of trying to
>figure out my own Contact, which may lead me to results that my proxy
>can't handle.
>
>It seems to me that if the Request-URI got to me, using it as a
>Contact field will also get to me.
>
>-- 
>Dvir Oren               
>Lucid VON Ltd.     
>9 Saloniki St.,        Tel-Aviv       Israel
>Tel:  +972 3 644 3038  Fax:  +972 3 644 3039
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
>



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


From sip-admin@lists.bell-labs.com  Wed Jul 26 01:29:53 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00382
	for ; Wed, 26 Jul 2000 01:29:52 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ED7964437D; Wed, 26 Jul 2000 01:29:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1631944338
	for ; Wed, 26 Jul 2000 01:29:46 -0400 (EDT)
Received: from dynamicsoft.com (1Cust52.tnt5.freehold.nj.da.uu.net [63.36.113.52])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16514;
	Wed, 26 Jul 2000 01:28:31 -0400 (EDT)
Message-ID: <397E779E.1F0BF4F8@dynamicsoft.com>
Date: Wed, 26 Jul 2000 01:31:10 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
Cc: Jo Hornsby , sip@lists.bell-labs.com
Subject: Re: [SIP] ACK handling at Stateful Proxies
References: <000c01bff647$4631e850$4e34c3c1@ubiquity.co.uk> <397E1726.5ADA57DD@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:
> 
> Jo Hornsby wrote:
> >
> > Hi,
> >
> > I'd just like to clarify the following.  Section 12.3.5 says the
> > following:
> > "When an ACK request is received, it is either processed locally
> >  or proxied. To make this determination, the To, From, CSeq and
> >  Call-ID fields are compared against those in previous requests.
> >  If there is no match, the ACK request is proxied as if it were
> >  an INVITE request. If there is a match, and if the server had
> >  ever sent a 200 response upstream, the ACK is proxied. If the
> >  server had never sent any responses upstream, the ACK is also
> >  proxied. If the server had sent a 3xx, 4xx, 5xx or 6xx response,
> >  but no 2xx response, the ACK is processed locally if the tag in
> >  the To field of the ACK matches the tag sent by the proxy in
> >  the response."
> >
> > Is it necessarily either/or?  According to the above paragraph, in
> > the case that a 200 arrives late, and the INVITE was not successful
> > (i.e., the proxy has already sent back a non-200), it will not
> > process the ACK locally (and thus will retransmit the response).
> 
> Not sure I get the scenario, but here's my interpretation:
> 
> - proxy times out branch (and sends CANCEL)
> - proxy sends some 4/5/6xx upstream
> - 200 arrives from the timed-out branch since it met the CANCEL in
> mid-flight
> - proxy forwards 200 upstream
> - UA ACKs both 4/5/6 and 200, as appropriate

Right, so Jo's point here I think is that the text discusses ACK
matching under
the assumption that only a single response was forwarded upstream, but
here there are 
multiple ones.

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 01:34:31 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03185
	for ; Wed, 26 Jul 2000 01:34:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D388A443A6; Wed, 26 Jul 2000 01:33:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 71BCF443A0
	for ; Wed, 26 Jul 2000 01:32:59 -0400 (EDT)
Received: from dynamicsoft.com (1Cust52.tnt5.freehold.nj.da.uu.net [63.36.113.52])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16520;
	Wed, 26 Jul 2000 01:34:31 -0400 (EDT)
Message-ID: <397E7906.568909AD@dynamicsoft.com>
Date: Wed, 26 Jul 2000 01:37:10 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rahul pande 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] some queries
References: <20000725142946.45855.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



rahul pande wrote:
> 
> hi all,
>     i have some questions to ask :
> 1) what is the use to the Via header fields ?

for routing responses back towards the UAC.

> 2) In one of the articles i had read that "UDP enables SIP to multicast"
> does it mean that TCP cannot be used for this.

TCP can never be used for multicast. This has nothing to do with SIP.

> 3) How do i issue multicast address, what is the mechanism?

You mean how do you send a SIP request to a multicast address? The rules
are the same for INVITE except:

1. servers don't transmit final responses other than 2xx, 401, 407 and
6xx
2. the sender really has to CANCEL upon getting the final response
3. servers can optionally suppress sending their 2xx, 401, 407, 6xx if
they see another server send one first.
 
> 4) if i want to send some text/plain message wiil i specify it like:
>       m=text  tcp plain in SDP?

Are you talking about instant messaging? This isn't how you would do
that:
http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-im-00.txt


> 5) who is the registration server is it my location server or any other
> entity?

You can discover a registration server using multicast, one can be
administratively configured, you can learn it through DHCP, or discover
it through SLP. Other possibilities exist as well.



>       I will reiterate that i am a novice and please convey to me the whole
> details even if the questions sound foolish.

You should check out the FAQ and the various tutorials and slides at:
http://www.cs.columbia.edu/~hgs/sip

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 01:43:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08904
	for ; Wed, 26 Jul 2000 01:43:48 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 37069443B3; Wed, 26 Jul 2000 01:41:35 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D4242443AA
	for ; Wed, 26 Jul 2000 01:41:29 -0400 (EDT)
Received: from dynamicsoft.com (1Cust52.tnt5.freehold.nj.da.uu.net [63.36.113.52])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16586;
	Wed, 26 Jul 2000 01:38:57 -0400 (EDT)
Message-ID: <397E7A10.8A2AAB70@dynamicsoft.com>
Date: Wed, 26 Jul 2000 01:41:36 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dvir Oren 
Cc: Jo Hornsby , SIP 
Subject: Re: [SIP] Using Request-URI
References: <14717.38550.94398.991570@jodie.lucid>
		<001101bff64e$fcfcef60$4e34c3c1@ubiquity.co.uk> <14717.59385.431537.899170@jodie.lucid>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Dvir Oren wrote:
> 
> It seems to me that if the Request-URI got to me, using it as a
> Contact field will also get to me.

Not necessarily. Proxy routing logic can be arbitrarily complex, and it
may have forwarded it to you based on some other criteria.

The safest best for Contact is generally sip:user@IPADDRESS.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 02:05: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 ESMTP id CAA24901
	for ; Wed, 26 Jul 2000 02:05:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 727AE4439D; Wed, 26 Jul 2000 02:05:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 4505244338
	for ; Wed, 26 Jul 2000 02:05:39 -0400 (EDT)
Received: from dynamicsoft.com (1Cust52.tnt5.freehold.nj.da.uu.net [63.36.113.52])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16753;
	Wed, 26 Jul 2000 02:07:11 -0400 (EDT)
Message-ID: <397E80AD.1A51C5EA@dynamicsoft.com>
Date: Wed, 26 Jul 2000 02:09:49 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sunitha Kumar 
Cc: SIPbell-labs 
Subject: Re: [SIP] Question on Contact, and Route in the draft.
References: <397CA827.B1FAC243@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Sunitha Kumar wrote:
> 
> Quoting from pg:68 ,
> If the request featured a Contact header field, the Contact header
> value is appended to the Route header list.
> 
> Is this the initial request? If that is so, it cannot have the Route
> header list.

It does refer to the initial request. Yes, that initial request doesn't
contain the Route header. The Route list the text is referring to is the
Route list constructed by the UAS used in subsequent requests back to
the caller, not a Route list present in the received original request
(there is none).

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 02:20:34 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29601
	for ; Wed, 26 Jul 2000 02:20:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D23B4443A6; Wed, 26 Jul 2000 02:20:24 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D2A51443A1
	for ; Wed, 26 Jul 2000 02:20:21 -0400 (EDT)
Received: from dynamicsoft.com (1Cust52.tnt5.freehold.nj.da.uu.net [63.36.113.52])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16790;
	Wed, 26 Jul 2000 02:21:49 -0400 (EDT)
Message-ID: <397E841C.B36AD2E@dynamicsoft.com>
Date: Wed, 26 Jul 2000 02:24:28 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Daniel Gardner 
Cc: Henning Schulzrinne ,
        Peter Kjellerstedt ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Inconsistencies and questions regarding latest 2543bis 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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Daniel Gardner wrote:
> 
> Should the section on locating a server (1.4.2) be updated to reflect
> point (1) below?

Actually, I think the table is right, and the text is wrong.
Parameters/maddr/port should be allowed in the request URI, but not in
the To/From. In that case, 1.4.2 need not be updated.

Henning wrote:
> > 1) Table 2 is not consistent with the text:
> >
> >    In the text about URL parameters it is specified that
> >    transport, maddr and ttl MUST NOT be present in From and To
> >    headers and in the Request-URI, but still they are listed
> >    in table 2 as optitional for the Request-URI.
> 
> Table changed.
> 

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 02: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 ESMTP id CAA01447
	for ; Wed, 26 Jul 2000 02:26:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0A63F443B1; Wed, 26 Jul 2000 02:26:00 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1AA55443AA
	for ; Wed, 26 Jul 2000 02:25:57 -0400 (EDT)
Received: from dynamicsoft.com (1Cust52.tnt5.freehold.nj.da.uu.net [63.36.113.52])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16814
	for ; Wed, 26 Jul 2000 02:27:30 -0400 (EDT)
Message-ID: <397E8571.BADFCFFB@dynamicsoft.com>
Date: Wed, 26 Jul 2000 02:30:09 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] volunteers needed!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Folks,

My first attempt at collecting open list issues has not been that
successful. Only two people sent me open issues they knew about, and I
am sure there is more than that. So, we will need to comb through the
archives. Given the massive volume of this list, that is a daunting
task. It would be easier if there were a bunch of people, each of which
could take a fraction of the archives and search through it. The more
people that volunteer, the easier it is for everyone.

So, I am now soliciting volunteers to help look through the archives,
starting with the week of the last IETF, to pick out issues raised but
never resolved. Send me a note if you are willing to help. I will take
the volunteers I get by Thursday midnight and divy up the list based on
the number. This is important. We don't want to lost important issues
raised on the list. Bringing sip to draft is a group process, requiring
cooperation and efforts of many. Please help...

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 02:36:27 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05473
	for ; Wed, 26 Jul 2000 02:36:27 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D7803443AB; Wed, 26 Jul 2000 02:36:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id BAE5344338
	for ; Wed, 26 Jul 2000 02:36:20 -0400 (EDT)
Received: from dynamicsoft.com (1Cust52.tnt5.freehold.nj.da.uu.net [63.36.113.52])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16826;
	Wed, 26 Jul 2000 02:34:05 -0400 (EDT)
Message-ID: <397E86FC.8F31E32C@dynamicsoft.com>
Date: Wed, 26 Jul 2000 02:36:44 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Neil Deason 
Cc: Jo Hornsby , Shail Bhatnagar ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <000701bff332$04f01320$4e34c3c1@ubiquity.co.uk> <397A8FAC.EE482A4E@dynamicsoft.com> <397C002F.FF57F091@ubiquity.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Neil Deason wrote:
> 
> > >
> > > As far as I can tell from 1.4.2, the maddr is either going to be
> > > an IP or a host name; if it's the latter, then clients perform
> > > an A (or AAAA, or whatever) lookup...
> >
> > and in the former, an SRV lookup.
> 
> I thought that if the maddr is the former, i.e. an IP address,
> the client is going to contact the server directly at that given
> address.  If it is a host name the client queries the DNS server
> for address records (A RR's, AAAA RR's) for the host portion of
> the maddr. Therefore no lookup for SRV records for a SIP server
> is done in Record-Routing.
> 

Right. I misread the order here and also did not realize that the draft
specification
says to use only A records if maddr contains a domain name. I'm not sure
why
this is there, actually. I guess its to make sure that subsequent
requests for the
same call go through exactly the same server. But, in this case, you
should put an IP address in to guarantee that. The advantage of the
domain name (and thus SRV lookup) is that, for stateless services or for
proxies which replicate state, you could route subsequent requests for
the same call through different servers, achieving some nice failover
properties.

-Jonathan R.



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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 02:40:14 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06721
	for ; Wed, 26 Jul 2000 02:40:14 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 037F9443BC; Wed, 26 Jul 2000 02:39:57 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 3E3DA443B7
	for ; Wed, 26 Jul 2000 02:39:55 -0400 (EDT)
Received: from dynamicsoft.com (1Cust52.tnt5.freehold.nj.da.uu.net [63.36.113.52])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16831;
	Wed, 26 Jul 2000 02:37:42 -0400 (EDT)
Message-ID: <397E87D5.DE4166C6@dynamicsoft.com>
Date: Wed, 26 Jul 2000 02:40:21 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Neil Deason 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com> <39782CCE.4BFF8A3E@ubiquity.net> <3978775A.BC475B21@dynamicsoft.com> <39787C95.481C3BDD@ubiquity.net> <397A8F76.BE9DB8AD@dynamicsoft.com> <397C14D0.EE94C286@ubiquity.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Neil Deason wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > Neil Deason wrote:
> > >
> > > >
> > > > If you put an IP address into the maddr parameter, yes, the port number
> > > > will need to be there if its not 5060. If you put a domain name, you
> > > > will not need it if you wish to rely on SRV records. If you are relying
> > > > on A records, again, you'll need it there. Record-routing with domain
> > > > names that point to SRV records can be both good and bad. If may cause
> > > > subsequent requests to go to a different server. Good for failover, bad
> > > > if you don't have state replication mechanisms in the back end between
> > > > servers.
> > >
> > > What about on reverse request paths where components other
> > > than the maddr param are taken from the originating name-addr
> > > value (i.e. Contact header or From header if there is no
> > > Contact). In this case isn't any port info placed in the
> > > Request-URI by a proxy wanting to be on the route lost.
> >
> > I can't seem to parse this response. Can you rephrase?
> 
> I was thinking about the possible effect of a proxy server
> relying on the mechanism of writing it's port number, if it is
> not 5060, in the Request-URI.

I think you mean Record-Route.

> In the case of reverse request
> paths wont this be useless? According to Section 6.35.2 ...
> 
> "Since the URIs contained in the Record-Route are not useful for
> the reverse request path, the UA fills all other components of
> the Route name-addr value with the originating name-addr value.
> The originating name-addr value is the name-addr value found in
> the Contact header of the request or the From header field, if
> there is no Contact header field."

I think I have mentioned already on the list that I believe the text in
6.35.2 is
wrong. Its not just the maddr copied from the Record-route, it would
also be port.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 04:00:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26121
	for ; Wed, 26 Jul 2000 04:00:48 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 607F844372; Wed, 26 Jul 2000 04:00:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 8799F44338
	for ; Wed, 26 Jul 2000 04:00:32 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id IAA01226; Wed, 26 Jul 2000 08:58:38 +0100 (BST)
From: "Jo Hornsby" 
To: "Henning Schulzrinne" 
Cc: 
Subject: RE: [SIP] ACK handling at Stateful Proxies
Date: Wed, 26 Jul 2000 08:58:39 +0100
Message-ID: <000401bff6d7$4eda63c0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <397E1726.5ADA57DD@cs.columbia.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> Not sure I get the scenario, but here's my interpretation:
> 
> - proxy times out branch (and sends CANCEL)
> - proxy sends some 4/5/6xx upstream
> - 200 arrives from the timed-out branch since it met the CANCEL in
> mid-flight
> - proxy forwards 200 upstream
> - UA ACKs both 4/5/6 and 200, as appropriate

Exactly right.  However, my interpretation of 12.3.5 is that the
proxy would not process the ACK locally in this case, since it
had forwarded a 2xx (admittedly, it's a bit of race -- the ACK
for the 4/5/6xx would have to arrive after the proxy had forwarded
the 2xx).  And tags in To headers cannot necessarily be used to
distinguish between ACKs, since this might be as the result of
a re-INVITE.

> The user agent section already has:
> 
> Multiple responses may arrive at the UAC for a single {\INVITE} request,
> due to a forking proxy.  Each response is distinguished by the
> ``\header{tag}'' parameter in the \header{To} header field, and each
> represents a distinct call leg.  The caller {\MAY} choose to acknowledge
> or terminate the call with each responding UAS.

Cool.  But doesn't this apply to clients in general?  And thus,
shouldn't it be stated that a client should attempt to ACK all
responses along a single branch with different tag parameters
in the To header?

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 Jul 26 04:46:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06562
	for ; Wed, 26 Jul 2000 04:46:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 87A8F44385; Wed, 26 Jul 2000 04:45:41 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 295B444338
	for ; Wed, 26 Jul 2000 04:45:33 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA11001; Wed, 26 Jul 2000 09:43:37 +0100 (BST)
From: "Jo Hornsby" 
To: 
Date: Wed, 26 Jul 2000 09:43:37 +0100
Message-ID: <000501bff6dd$97661c00$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
Subject: [SIP] Receiver-tagged Via headers and ports.  Again.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

Since my point about the received-port being ignored in 6.47.3
was missed (I can't understand this because I'd buried it as
a really small point in a completely unrelated post (:&), I'm
reraising.

I think that given the sentence in 6.47.2:
"If and only if the source address and port differ from the
 sent-by address, the proxy also includes the source port in
 the received parameter."
Shouldn't the text in 6.47.3 be updated to use this port if
it is present and there is no maddr?

Furthermore, shouldn't 6.47.4 be updated similarly, so that
servers -- be they proxy or UA -- behave identically?

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 Jul 26 05:20:23 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13872
	for ; Wed, 26 Jul 2000 05:20:23 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 18D6944384; Wed, 26 Jul 2000 05:20:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38])
	by lists.bell-labs.com (Postfix) with ESMTP id 95ECE44338
	for ; Wed, 26 Jul 2000 05:20:07 -0400 (EDT)
Received: from pqm-cons.demon.co.uk ([158.152.93.237] helo=P162U)
	by finch-post-10.mail.demon.net with smtp (Exim 2.12 #1)
	id 13HNMA-000Dle-0A; Wed, 26 Jul 2000 09:20:03 +0000
From: "Alex Hardisty" 
To: "Henning Schulzrinne" , 
Cc: 
Subject: RE: [SIP] rfc2543bis: table 4 comments
Date: Wed, 26 Jul 2000 10:22:34 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <397E0FCE.5D807D95@cs.columbia.edu>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Brett Tate wrote:

> Row "Content-Length" should be all "o" if the last two
> paragraphs in section 6.19 are correct.

Henning Schulzrinne wrote:

> It says "SHOULD" for Content-Length, so this is probably closer to 'm'
> than 'o'.

My interpretation of the text "as written" is that it is (according to table
4) mandatory to include the Content-Length in all Methods. The last two
paragraphs of 6.17 specify how the application ought to use this field
(however, according to the RFC2119 definition of "should" there may be valid
reasons why the application could use the field in a different way).
However, there is no indication that the field can be omitted.

If my interpretation is correct then:

1) This seems to be a significant change from the original RFC where
inclusion of the field was indicated as optional in table 4. How would this
affect backwards compatibility?

2) Perhaps it would be useful to add the sentence "It must be included in
every request" after the first sentence of 6.17.

3) There appears to be an inconsistency between the mandatory requirement to
include the field and the sentence of 6.17 referring to the case when it is
absent in a received request. If a mandatory field is absent, oughtn't it to
be treated as a protocol error?

I'm ready to be corrected in my interpretation!

--
Alex Hardisty
PQM Consultants



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


From sip-admin@lists.bell-labs.com  Wed Jul 26 05:26:18 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15160
	for ; Wed, 26 Jul 2000 05:26:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D9FD44438A; Wed, 26 Jul 2000 05:25:40 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id F2D4C44338
	for ; Wed, 26 Jul 2000 05:25:30 -0400 (EDT)
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id KAA13052; Wed, 26 Jul 2000 10:23:08 +0100 (BST)
Message-ID: <397EAE00.81DE153E@ubiquity.net>
Date: Wed, 26 Jul 2000 10:23:12 +0100
From: Neil Deason 
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com> <39782CCE.4BFF8A3E@ubiquity.net> <3978775A.BC475B21@dynamicsoft.com> <39787C95.481C3BDD@ubiquity.net> <397A8F76.BE9DB8AD@dynamicsoft.com> <397C14D0.EE94C286@ubiquity.net> <397E87D5.DE4166C6@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Neil Deason wrote:
> >
> > Jonathan Rosenberg wrote:
> > >
> > > Neil Deason wrote:
> > > >
> > > > >
> > > > > If you put an IP address into the maddr parameter, yes, the port number
> > > > > will need to be there if its not 5060. If you put a domain name, you
> > > > > will not need it if you wish to rely on SRV records. If you are relying
> > > > > on A records, again, you'll need it there. Record-routing with domain
> > > > > names that point to SRV records can be both good and bad. If may cause
> > > > > subsequent requests to go to a different server. Good for failover, bad
> > > > > if you don't have state replication mechanisms in the back end between
> > > > > servers.
> > > >
> > > > What about on reverse request paths where components other
> > > > than the maddr param are taken from the originating name-addr
> > > > value (i.e. Contact header or From header if there is no
> > > > Contact). In this case isn't any port info placed in the
> > > > Request-URI by a proxy wanting to be on the route lost.
> > >
> > > I can't seem to parse this response. Can you rephrase?
> >
> > I was thinking about the possible effect of a proxy server
> > relying on the mechanism of writing it's port number, if it is
> > not 5060, in the Request-URI.
> 
> I think you mean Record-Route.

Well yes, I meant the URI taken from the incoming Request-URI 
once it had been copied into the Record-Route.

> > In the case of reverse request
> > paths wont this be useless? According to Section 6.35.2 ...
> >
> > "Since the URIs contained in the Record-Route are not useful for
> > the reverse request path, the UA fills all other components of
> > the Route name-addr value with the originating name-addr value.
> > The originating name-addr value is the name-addr value found in
> > the Contact header of the request or the From header field, if
> > there is no Contact header field."
> 
> I think I have mentioned already on the list that I believe the text in
> 6.35.2 is wrong. 

Can you recall the thread - I have searched back to no avail.

> Its not just the maddr copied from the Record-route, it would
> also be port.

This would potentially mean building a new SIP URL by 
combining the maddr + port from the one in the Record-Route 
with the other elements of one in the Contact/From. This 
really represents a meaningless SIP URL. This ugliness 
seems to come about beacuse we are overloading the port 
part of the SIP URL in the Record-Route header to 
represent port of a proxy on the route. Is adding a new 
param for the proxy-port not an alternative?

At this point, and pre-IETF/Bakeoff, perhaps it is also 
worth re-raising the issue of a proxy being able to add 
something into the Record-Route to indicate call state. 
This was discussed at the 4th bakeoff but it was pointed 
out using a rr-extension is no use as a proxy wouldn't get 
it back via the Route header as this gets stripped off. If 
there is a real desire to achieve this perhaps something 
added in the name-addr part could work as the proxy should 
get this as part of the incoming Request-URI?

Finally Jo has pointed out to me that maybe the spec also
wants to say that a server MUST NOT add itself more than
once into the Record-Route. Otherwise this could happen on 
a 'legal' loop and the subsequent requests on the call leg
fail due to an illegal loop being created.

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 Jul 26 09:15:33 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07941
	for ; Wed, 26 Jul 2000 09:15:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 660A144384; Wed, 26 Jul 2000 09:15:21 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id BBE7A44338
	for ; Wed, 26 Jul 2000 09:15:17 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6QDFGQ09825
	for ; Wed, 26 Jul 2000 15:15:16 +0200 (MEST)
Received: from SMTP ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1);
	 Wed, 26 Jul 2000 15:15:16 +0200
Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by 153.88.251.29
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 26 Jul 2000 13:15:15 0000 (GMT)
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id ; Wed, 26 Jul 2000 15:15:14 +0200
Message-ID: <56E7307B0850D411B1480008C75DD5EAB73BE6@enlrynt303.dsn.ericsson.se>
From: "Arnoud van Wijk (ETM)" 
To: "'sip@lists.bell-labs.com'" 
Date: Wed, 26 Jul 2000 15:13:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-OriginalArrivalTime: 26 Jul 2000 13:15:16.0188 (UTC) FILETIME=[89FFF9C0:01BFF703]
Subject: [SIP] COMET pathway
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


I was reading the internet draft: 
It talks about QoS and using the COMET method.

One thing is a bit unclear to me.
Does a COMET message follow the SAME pathway as the SIP INVITE message?. Or does the COMET follow the pathway that has been reserved (according to resource requests)? (see point 5. SIP extension: The COMET Method).
Like that the COMET message is the first "user" of the reserved pathway. 

I appreciate any feedback.
Thanks

Arnoud van Wijk

_______________________________________________________________
ERICSSON TELECOMMUNICATIE BV
Arnoud van Wijk
Research & Development
ETM/BL/RE
Fax: +31-161 247569
_______________________________________________________________





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


From sip-admin@lists.bell-labs.com  Wed Jul 26 09:30:19 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10317
	for ; Wed, 26 Jul 2000 09:30:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BFA404438A; Wed, 26 Jul 2000 09:30:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mushroom.icoe.net (icoe-gate.icoe.att.nl [194.242.71.50])
	by lists.bell-labs.com (Postfix) with ESMTP id 5BEAF44389
	for ; Wed, 26 Jul 2000 09:30:12 -0400 (EDT)
Received: by mushroom.icoe.net; id PAA20216; Wed, 26 Jul 2000 15:30:11 +0200 (CEST)
Received: from unknown(135.76.170.11) by mushroom.icoe.net via smap (4.0a)
	id xma020209; Wed, 26 Jul 00 15:30:05 +0200
Received: from blackberry (mikan.icoe.att.com [135.76.170.4])
	by watermelon.icoe.att.com (Postfix) with ESMTP
	id C69E711581; Wed, 26 Jul 2000 15:30:03 +0200 (MET DST)
Message-Id: <4.2.0.58.20000726152540.02d81ba0@watermelon.icoe.att.com>
X-Sender: romeo@watermelon.icoe.att.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 26 Jul 2000 15:28:41 +0200
To: "Arnoud van Wijk (ETM)" 
From: Romeo Zwart 
Subject: Re: [SIP] COMET pathway
Cc: "'sip@lists.bell-labs.com'" 
In-Reply-To: <56E7307B0850D411B1480008C75DD5EAB73BE6@enlrynt303.dsn.eric
 sson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi Arnoud,

Not sure if the I-D talks about it explicitly, but it would seem obvious that 
the COMET is on the signalling path, not on the (reserved) media path. 

Romeo

At 03:13 PM 26-07-00 +0200, Arnoud van Wijk (ETM) wrote:

>I was reading the internet draft: 
>It talks about QoS and using the COMET method.
>
>One thing is a bit unclear to me.
>Does a COMET message follow the SAME pathway as the SIP INVITE message?. Or does the COMET follow the pathway that has been reserved (according to resource requests)? (see point 5. SIP extension: The COMET Method).
>Like that the COMET message is the first "user" of the reserved pathway. 
>
>I appreciate any feedback.
>Thanks
>
>Arnoud van Wijk
>
>_______________________________________________________________
>ERICSSON TELECOMMUNICATIE BV
>Arnoud van Wijk
>Research & Development
>ETM/BL/RE
>Fax: +31-161 247569
>_______________________________________________________________
>
>
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/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 Jul 26 09:32:54 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10926
	for ; Wed, 26 Jul 2000 09:32:53 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A2B8544395; Wed, 26 Jul 2000 09:32:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 67D3744390
	for ; Wed, 26 Jul 2000 09:31:58 -0400 (EDT)
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id TAA26277;
	Wed, 26 Jul 2000 19:02:11 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Wed, 26 Jul 2000 19:02:10 +0000 (IST)
Received: from pcg140 (pcg140.sasi.com [10.0.64.140])
	by sung17.sasi.com (8.9.3/8.9.3) with SMTP id TAA11063;
	Wed, 26 Jul 2000 19:02:09 +0530 (IST)
Message-ID: <01d001bff705$877d5ba0$8c40000a@sasi.com>
From: "rafi" 
To: "Arnoud van Wijk (ETM)" ,
        
References: <56E7307B0850D411B1480008C75DD5EAB73BE6@enlrynt303.dsn.ericsson.se>
Subject: Re: [SIP] COMET pathway
Date: Wed, 26 Jul 2000 18:59:30 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: Arnoud van Wijk (ETM) 
To: 
Sent: Wednesday, July 26, 2000 6:43 PM
Subject: [SIP] COMET pathway


>
> I was reading the internet draft: 
> It talks about QoS and using the COMET method.
>
> One thing is a bit unclear to me.
> Does a COMET message follow the SAME pathway as the SIP INVITE message?.
Or does the COMET follow the pathway that has been reserved (according to
resource requests)? (see point 5. SIP extension: The COMET Method).
> Like that the COMET message is the first "user" of the reserved pathway.

   COMET is like any other SIP message  when we consider its
   pathway. For e.g., if  a response to INVITE message contained
  a contact address then  COMET can  be directly send to that address.
  COMET can also go via proxies if there was a  Record-Route
  parameter.

   Pathway that has been reserved is only for sending and
   receiving media and not for sending SIP messages.

Regards
Rafi Assadi H.M.





>
> I appreciate any feedback.
> Thanks
>
> Arnoud van Wijk
>
> _______________________________________________________________
> ERICSSON TELECOMMUNICATIE BV
> Arnoud van Wijk
> Research & Development
> ETM/BL/RE
> Fax: +31-161 247569
> _______________________________________________________________
>
>
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Jul 26 09:34:36 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11323
	for ; Wed, 26 Jul 2000 09:34:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BE004443A1; Wed, 26 Jul 2000 09:34:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id CB6914439C
	for ; Wed, 26 Jul 2000 09:34:07 -0400 (EDT)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id IAA24157;
	Wed, 26 Jul 2000 08:34:04 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id IAA10501;
	Wed, 26 Jul 2000 08:34:03 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA01092; Wed, 26 Jul 2000 08:34:02 -0500 (CDT)
From: Sean Olson 
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id IAA11255;
	Wed, 26 Jul 2000 08:34:01 -0500 (CDT)
Date: Wed, 26 Jul 2000 08:34:01 -0500 (CDT)
Message-Id: <200007261334.IAA11255@b04a45.exu.ericsson.se>
To: sip@lists.bell-labs.com, jhornsby@ubiquity.net
Subject: Re: [SIP] Receiver-tagged Via headers and ports.  Again.
X-Sun-Charset: US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

> Hi,
> 
> Since my point about the received-port being ignored in 6.47.3
> was missed (I can't understand this because I'd buried it as
> a really small point in a completely unrelated post (:&), I'm
> reraising.
> 
> I think that given the sentence in 6.47.2:
> "If and only if the source address and port differ from the
>  sent-by address, the proxy also includes the source port in
>  the received parameter."
> Shouldn't the text in 6.47.3 be updated to use this port if
> it is present and there is no maddr?
> 
> Furthermore, shouldn't 6.47.4 be updated similarly, so that
> servers -- be they proxy or UA -- behave identically?

I'm glad you pointed this out. Using the source port over the port
specified in the sent-by address seems to be a mistake. For example,
if the Via: sent-by address differs from the source IP address and
does not specify a port (implying port 5060), then do you add the
port to the via-received parameter (in the event it is not 5060)? 

This seems inconsistent with the previous notion that you ignore the
source port in ALL cases and instead use the port as specified.

In any case, the behaviour should be well defined and consistent
throughout the draft as Jo pointed out.

 
> Cheers,
>  - Jo.
> -- 
>   Jo Hornsby; IT Professional         --       mailto:jhornsby@ubiquity.net
>  Ubiquity Software Corporation        --         http://www.ubiquity.net/
 

--
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  Wed Jul 26 09:46:23 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13616
	for ; Wed, 26 Jul 2000 09:46:22 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7C3A744390; Wed, 26 Jul 2000 09:46:20 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 1D2B744338
	for ; Wed, 26 Jul 2000 09:46:17 -0400 (EDT)
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 IAA28972;
	Wed, 26 Jul 2000 08:46:16 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id IAA20375;
	Wed, 26 Jul 2000 08:46:16 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA01655; Wed, 26 Jul 2000 08:46:14 -0500 (CDT)
From: Sean Olson 
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id IAA11262;
	Wed, 26 Jul 2000 08:46:13 -0500 (CDT)
Date: Wed, 26 Jul 2000 08:46:13 -0500 (CDT)
Message-Id: <200007261346.IAA11262@b04a45.exu.ericsson.se>
To: jdrosen@dynamicsoft.com, ndeason@ubiquity.net
Subject: Re: [SIP] Record-Route and maddr
Cc: sip@lists.bell-labs.com
X-Sun-Charset: US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com


> From sip-admin@lists.bell-labs.com  Wed Jul 26 04:26:53 2000
> Delivered-To: sip@lists.bell-labs.com
> Date: Wed, 26 Jul 2000 10:23:12 +0100
> From: Neil Deason 
> Organization: Ubiquity Software Corporation Limited
> X-Mailer: Mozilla 4.51 [en] (WinNT; I)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: Jonathan Rosenberg 
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] Record-Route and maddr
> Content-Transfer-Encoding: 7bit
> Sender: sip-admin@lists.bell-labs.com
> X-Mailman-Version: 1.1
> List-Id: IETF SIP Mailing List 
> X-BeenThere: sip@lists.bell-labs.com
> 
> Jonathan Rosenberg wrote:
> > 
> > Neil Deason wrote:
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > > Neil Deason wrote:
> > > > >
> > > > > >
> > > > > > If you put an IP address into the maddr parameter, yes, the port number
> > > > > > will need to be there if its not 5060. If you put a domain name, you

> At this point, and pre-IETF/Bakeoff, perhaps it is also 
> worth re-raising the issue of a proxy being able to add 
> something into the Record-Route to indicate call state. 
> This was discussed at the 4th bakeoff but it was pointed 
> out using a rr-extension is no use as a proxy wouldn't get 
> it back via the Route header as this gets stripped off. If 
> there is a real desire to achieve this perhaps something 
> added in the name-addr part could work as the proxy should 
> get this as part of the incoming Request-URI?

It was also suggested at the last bakeoff that the Record-route
(and any extensions) should be kept intact and copied verbatim into
the Route header ... but that has obviously changed. 

It would be nice to see the State: header extension proposed by the
DCS group used for this purpose rather than inventing a new 
mechanism. Comments?

--
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  Wed Jul 26 10:32:22 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20014
	for ; Wed, 26 Jul 2000 10:32:22 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 88EB64439E; Wed, 26 Jul 2000 10:31:25 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from polaris.shore.net (polaris.shore.net [207.244.124.105])
	by lists.bell-labs.com (Postfix) with ESMTP id F2F7544338
	for ; Wed, 26 Jul 2000 10:31:19 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by polaris.shore.net with esmtp (Exim)
	for sip@lists.bell-labs.com
	id 13HSDE-00057j-00; Wed, 26 Jul 2000 10:31:08 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id KAA20398;
	Wed, 26 Jul 2000 10:24:32 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Jul 2000 10:31:51 -0400
To: sip@lists.bell-labs.com
From: David Yon 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] SIP, SDP, and TCP-based media transport
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Attached is an informal discussion of various approaches to solving the 
SDP/TCP problem.  Any comments are welcome.  If there is general agreement 
I'd be happy to collaborate on or submit a formal I-D.

With FOGLAMPS under way, and T.38 Annex D already finalized, this problem 
needs to be solved as soon as possible.  While this may be more of an SDP 
issue than a SIP issue, this problem is directly relevant to SIP which is 
why I've posted this here.  If anyone has suggestions for additional and/or 
more appropriate forums please let me know.


----

		SIP, SDP, and TCP-based media transport
		=======================================
	
The Session Description Protocol currently only describes a small set of 
protocols that are used for media transport, the most common being RTP and 
UDP.  A significant omission in SDP is a way to specify TCP as the 
transport protocol.  Since SIP uses SDP to describe the media used in the 
session being initiated, there is currently no way to use SIP to set up 
sessions that use TCP connections for media transport.

Annex D of the T.38 spec recommends that a protocol identifier of "TCP" be 
added to SDP.  While this allows SDP to describe that the media transport 
will use TCP as the network protocol, it only tells half the story.  The 
major difference between RTP/UDP and TCP is that connection setup is 
asymmetric---one side must be the initiator and the other must be the 
listener.  Only specifying that the network protocol is TCP omits this 
important piece of information.

The remainder of this document discusses ways that the direction of the TCP 
connection setup could be conveyed in SDP.


Specification By Inference
--------------------------

One approach is to leave the decision to the endpoints, and just assume 
that if they can agree on a media transport that they'll implicitly know 
how to correctly set up the connection.  For example, a transport type of 
"t38" over TCP might imply that the caller always initiates the connection 
and the callee accepts the connection.

The problem is that it doesn't scale.  It requires that SIP ALP's stay 
current on an ever-growing list of transport types and hard-code their 
connection heuristics.


Mapping to SIP Call Flow
------------------------

Another approach is to standardize on mapping the SIP call direction to the 
connection of the TCP setup.  I.e., specify in the SIP RFC that the UA that 
does the INVITE is the one that accepts the TCP connection from the UA that 
does the OK.

The problem with this is that it imposes an arbitrary restriction upon a 
wide range of applications and topologies.  The transport may involve a 
legacy protocol that cares about the direction of the TCP setup, and it may 
not always map to the direction of the call flow.

The other problem is that it resolves the issue only for SIP, leaving the 
problem to be solved again and again for other protocols that also use SDP.


First-Specified/First-Served
----------------------------

One could specify that the first UA to offer up an SDP message is 
implicitly offering to accept the TCP connection.  This maps somewhat to 
how SDP works on UDP-based transports, where by specifying a port number 
the UA is announcing that the port is now available to accept a media stream.

This technique would certainly work when the topology allows the UA sending 
the INVITE to accept the TCP connection.  But if the topology requires that 
it be the UA sending the OK, then you run into the problem of 
underspecifying the session type.  Most sessions signalled in SIP are 
described by the SDP being sent in the INVITE.  I.e., is this an audio 
call?  an audio/video call?  a T.38 fax call?  This question can be 
answered by inspecting the SDP in the INVITE.  Not sending this information 
may deprive downstream SIP proxies of critical information required to 
select the correct media gateway.


Port Zero
---------

Another twist that would leave SDP syntax unchanged would be to establish 
the convention that an SDP message specifying zero for the port and TCP for 
a transport is the UA that will initiate the TCP connection.  It would be 
up to the other UA to supply a valid port that will accept this connection.

One problem is that this limits the flexibility of the network 
topology.  Many TCP protocols have a well-known port at which they will 
accept connections, and it may be desirable to always use that port number 
for the accept (not the least of which is ease of dumb-firewall 
administration).  If this is the case, specifying port zero for the 
initiator means that the acceptor may not have sufficient information to 
correlate an incoming connection with a SIP session.


TCP/S and TCP/C
---------------

The most explicit way to fully describe TCP-based transport is to add two 
new SDP protocol descriptors: TCP/S and TCP/C (any better suggestions for 
nomenclature?).  The UA that will accept the connection specifies TCP/S 
along with the port number it will be accepting on.  The UA that will 
initiate the connection specifies TCP/C along with the port number to which 
it has bound the outgoing socket.

This approach has numerous advantages.  The SDP messages convey *exactly* 
what will be occurring for media transport, and SIP ALP's will be able to 
Do The Right Thing(tm) for TCP-based transports with a minimum of extra 
complexity.  TCP-based servers can continue to use fixed port numbers for 
incoming connections if that is desirable.  At the same time, connections 
can be mapped to sessions without using additional signaling in the media 
transport itself.  Even dumb firewalls can easily be configured to pass 
this type of traffic (although NAT's remain a problem).


SSL/S and SSL/C?
----------------

Any reason to add these to the list?  One could argue that this belongs in 
the description of the upper-layer protocol.  On the other hand, it's 
common enough that it may warrant being added to the list of well-known SDP 
transports.  Comments?


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 Jul 26 14:54:27 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15850
	for ; Wed, 26 Jul 2000 14:54:27 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AE51444384; Wed, 26 Jul 2000 14:53:35 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id C0E4E44338
	for ; Wed, 26 Jul 2000 14:53:30 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA07899;
	Wed, 26 Jul 2000 14:53:28 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA01767;
	Wed, 26 Jul 2000 14:53:27 -0400 (EDT)
Message-ID: <397F33A6.E874C0C3@cs.columbia.edu>
Date: Wed, 26 Jul 2000 14:53:26 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Jo Hornsby , sip@lists.bell-labs.com
Subject: Re: [SIP] ACK handling at Stateful Proxies
References: <000c01bff647$4631e850$4e34c3c1@ubiquity.co.uk> <397E1726.5ADA57DD@cs.columbia.edu> <397E779E.1F0BF4F8@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Henning Schulzrinne wrote:
> >
> > Jo Hornsby wrote:
> > >
> > > Hi,
> > >
> > > I'd just like to clarify the following.  Section 12.3.5 says the
> > > following:
> > > "When an ACK request is received, it is either processed locally
> > >  or proxied. To make this determination, the To, From, CSeq and
> > >  Call-ID fields are compared against those in previous requests.
> > >  If there is no match, the ACK request is proxied as if it were
> > >  an INVITE request. If there is a match, and if the server had
> > >  ever sent a 200 response upstream, the ACK is proxied. If the
> > >  server had never sent any responses upstream, the ACK is also
> > >  proxied. If the server had sent a 3xx, 4xx, 5xx or 6xx response,
> > >  but no 2xx response, the ACK is processed locally if the tag in
> > >  the To field of the ACK matches the tag sent by the proxy in
> > >  the response."
> > >
> > > Is it necessarily either/or?  According to the above paragraph, in
> > > the case that a 200 arrives late, and the INVITE was not successful
> > > (i.e., the proxy has already sent back a non-200), it will not
> > > process the ACK locally (and thus will retransmit the response).
> >
> > Not sure I get the scenario, but here's my interpretation:
> >
> > - proxy times out branch (and sends CANCEL)
> > - proxy sends some 4/5/6xx upstream
> > - 200 arrives from the timed-out branch since it met the CANCEL in
> > mid-flight
> > - proxy forwards 200 upstream
> > - UA ACKs both 4/5/6 and 200, as appropriate
> 
> Right, so Jo's point here I think is that the text discusses ACK
> matching under
> the assumption that only a single response was forwarded upstream, but
> here there are
> multiple ones.

I simplified section 12.3.5 to read

When an {\ACK} request is received, it is proxied unless the request's
\header{To} (including the tag), \header{From}, \header{CSeq} and
\header{Call-ID} header fields match those of a (non-200) response sent
by the proxy.  In that case, the request is processed locally and stops
retransmissions of responses.

I believe that handles the multiple-ACK case and is simpler. It does
require that a server keep track of which non-2xx response it has
forwarded, since it needs to match the To tag.

Let me know if I missed any tag subtleties...
-- 
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 Jul 26 15:08:15 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17736
	for ; Wed, 26 Jul 2000 15:08:15 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 540CE4438A; Wed, 26 Jul 2000 15:08:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 5DDB344338
	for ; Wed, 26 Jul 2000 15:08:00 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA08571;
	Wed, 26 Jul 2000 15:07:58 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA02204;
	Wed, 26 Jul 2000 15:07:57 -0400 (EDT)
Message-ID: <397F370D.716F6C3E@cs.columbia.edu>
Date: Wed, 26 Jul 2000 15:07:57 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Daniel Gardner ,
        Peter Kjellerstedt ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Inconsistencies and questions regarding latest 2543bis draft
References:  <397E841C.B36AD2E@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Daniel Gardner wrote:
> >
> > Should the section on locating a server (1.4.2) be updated to reflect
> > point (1) below?
> 
> Actually, I think the table is right, and the text is wrong.
> Parameters/maddr/port should be allowed in the request URI, but not in
> the To/From. In that case, 1.4.2 need not be updated.
> 

Added a motivation. These parameters are needed only for outbound
proxies, as far as I can tell.

-- 
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 Jul 26 15:36:37 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22849
	for ; Wed, 26 Jul 2000 15:36:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5E9C64438D; Wed, 26 Jul 2000 15:35:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 20E9844338
	for ; Wed, 26 Jul 2000 15:35:39 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA10294;
	Wed, 26 Jul 2000 15:35:38 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA02973;
	Wed, 26 Jul 2000 15:35:38 -0400 (EDT)
Message-ID: <397F3D89.EC66C3C7@cs.columbia.edu>
Date: Wed, 26 Jul 2000 15:35:37 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Neil Deason , Jo Hornsby ,
        Shail Bhatnagar , sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <000701bff332$04f01320$4e34c3c1@ubiquity.co.uk> <397A8FAC.EE482A4E@dynamicsoft.com> <397C002F.FF57F091@ubiquity.net> <397E86FC.8F31E32C@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 

> 
> Right. I misread the order here and also did not realize that the draft
> specification
> says to use only A records if maddr contains a domain name. I'm not sure
> why
> this is there, actually. I guess its to make sure that subsequent
> requests for the
> same call go through exactly the same server. But, in this case, you
> should put an IP address in to guarantee that. The advantage of the
> domain name (and thus SRV lookup) is that, for stateless services or for
> proxies which replicate state, you could route subsequent requests for
> the same call through different servers, achieving some nice failover
> properties.

Makes sense. Changed to normal (DNS SRV, etc.) lookup procedure:


\item If the \header{maddr} parameter exists, it becomes the
\emph{destination address} used below; if not, the \header{host} element
in the \header{Request-URI} is the destination address.

\item If the destination address is an IP address, the client contacts
the server at the given address and ignores the remaining steps.

\item The \header{Request-URI} is examined. If it contains an explicit
port number other than 5060, the next two steps are skipped.

\item If the \header{Request-URI} specifies a transport protocol is
supported by the client, the client queries the name server for SRV
records for SIP servers of that protocol type only.  Otherwise, it goes
to the next step.

If the client does not support the protocol specified in the
\header{Request-URI}, it gives up.  The searching technique outlined in
RFC 2782 \cite{rfc2782} is used to select servers from the DNS response
in order.  If DNS does not return any records, the user goes to the last
step.  Otherwise, the user attempts to contact each server in the order
listed.  If no server is contacted, the user gives up.

\item If the \header{Request-URI} does not specify a protocol, the
client queries the name server for SRV records for all transport
protocols supported by the client.  The format of these queries is
defined in RFC 2782 \cite{rfc2782}.  The results of the query or queries
are merged and ordered based on priority.  Then, the searching technique
outlined in RFC 2782 \cite{rfc2782} is used to select servers in order.
If DNS does not return any records, the user goes to the last step.
Otherwise, the user attempts to contact each server in the order listed.
If none of the servers can be contacted, the user gives up.

\item The client queries the DNS server for address records for the
destination address.  Address records include A RR's, AAAA RR's, or
other similar records, chosen according to the client's network protocol
capabilities.  If the DNS server returns no address records, the client
stops, as it has been unable to locate a 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 Jul 26 15:47:05 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25442
	for ; Wed, 26 Jul 2000 15:47:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8203044395; Wed, 26 Jul 2000 15:46:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 40D3544390
	for ; Wed, 26 Jul 2000 15:46:42 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA10788;
	Wed, 26 Jul 2000 15:46:41 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA03256;
	Wed, 26 Jul 2000 15:46:41 -0400 (EDT)
Message-ID: <397F4021.D1227B03@cs.columbia.edu>
Date: Wed, 26 Jul 2000 15:46:41 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Neil Deason , sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com> <39782CCE.4BFF8A3E@ubiquity.net> <3978775A.BC475B21@dynamicsoft.com> <39787C95.481C3BDD@ubiquity.net> <397A8F76.BE9DB8AD@dynamicsoft.com> <397C14D0.EE94C286@ubiquity.net> <397E87D5.DE4166C6@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 

> 
> I think I have mentioned already on the list that I believe the text in
> 6.35.2 is
> wrong. Its not just the maddr copied from the Record-route, it would
> also be port.
> 

Changed to:

If a UA finds a \header{Record-Route} header in a request received as a
UAS, it copies the \header{Record-Route} \header{maddr} parameters and
any \header{port} value, maintaining their ordering, to the
\header{Route} header field of future requests issued as a UAC.  Since
the URIs contained in the \header{Record-Route} header fields are not
useful for the reverse request path, the UA fills all other components
of the \header{Route} \header{name-addr} value with the
\header{name-addr} value found in the \header{Contact} or the
\header{From} header field.  The latter is used only if there is no
\header{Contact} header field.


-- 
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 Jul 26 15:56:40 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29086
	for ; Wed, 26 Jul 2000 15:56:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D674C44383; Wed, 26 Jul 2000 15:56:22 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 5985644338
	for ; Wed, 26 Jul 2000 15:56:19 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA11221;
	Wed, 26 Jul 2000 15:56:11 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA03543;
	Wed, 26 Jul 2000 15:56:10 -0400 (EDT)
Message-ID: <397F425A.A0D7F126@cs.columbia.edu>
Date: Wed, 26 Jul 2000 15:56:10 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson 
Cc: sip@lists.bell-labs.com, jhornsby@ubiquity.net
Subject: Re: [SIP] Receiver-tagged Via headers and ports.  Again.
References: <200007261334.IAA11255@b04a45.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Sean Olson wrote:
> 

> 
> I'm glad you pointed this out. Using the source port over the port
> specified in the sent-by address seems to be a mistake. For example,
> if the Via: sent-by address differs from the source IP address and
> does not specify a port (implying port 5060), then do you add the
> port to the via-received parameter (in the event it is not 5060)?
> 
> This seems inconsistent with the previous notion that you ignore the
> source port in ALL cases and instead use the port as specified.
> 
> In any case, the behaviour should be well defined and consistent
> throughout the draft as Jo pointed out.
> 
> 

Please be sure to cite version of the draft (date) and section. I can't
find the section you're referring in "Responses".

The .4 version was a temporary glitch due to an attempt to deal with
NAPTs, but the conclusion was that this was more confusing than helpful.
Restored to a hopefully consistent state.

A different issue is whether receiver-tagging is worth the complexity,
given that NATs have to do ALG translation anyway. It is not clear when
this would actually be helpful.


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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 16: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 ESMTP id QAA10587
	for ; Wed, 26 Jul 2000 16:30:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3C91D44389; Wed, 26 Jul 2000 16:29:40 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from web116.yahoomail.com (web116.yahoomail.com [205.180.60.89])
	by lists.bell-labs.com (Postfix) with SMTP id 5BD5444338
	for ; Wed, 26 Jul 2000 16:29:36 -0400 (EDT)
Received: (qmail 2966 invoked by uid 60001); 26 Jul 2000 20:29:32 -0000
Message-ID: <20000726202932.2965.qmail@web116.yahoomail.com>
Received: from [149.112.219.153] by web116.yahoomail.com; Wed, 26 Jul 2000 13:29:32 PDT
Date: Wed, 26 Jul 2000 13:29:32 -0700 (PDT)
From: Andi Janti 
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] how is the proxy talks to the other proxy ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi, all

I'm pretty new on this SIP issue and I was wondering
how exactly the proxy server talks to other proxy
server ?
I am quite familiar with the H.323 gatekeeper talk
which is usually done with LRQ message when one gk is
communicating with another gk.

Is there some kind of mechanism how the SIP proxy
server communicates with each other ?
Or maybe do SIP has a similar spec called
administration zone/domain just like on H.323 ?

A few related questions, if the proxy server that is
serving the UAC doesn't know the destination address,
how is the proxy server resolve the called address ?
Do they need to talk to location server (such as DNS)
all the way to the top until it finds the address or
the proxy needs to communicate with another available
proxy server on the SIP network ?

Thank you.
--
Andi

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 16:52:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15743
	for ; Wed, 26 Jul 2000 16:52:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 92E204439F; Wed, 26 Jul 2000 16:51:50 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id 5B06544338
	for ; Wed, 26 Jul 2000 16:51:47 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id QAA28573; Wed, 26 Jul 2000 16:51:42 -0400 (EDT)
Message-ID: <0b5501bff743$d752f1b0$3102a8c0@broadsoft.com>
From: "Brett Tate" 
To: "SIPbell-labs" 
Date: Wed, 26 Jul 2000 16:55:32 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0B52_01BFF722.4F69DD70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] rfc2543bis 18x responses with SDP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_0B52_01BFF722.4F69DD70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

During draft-ietf-sip-183-00 incorporation into rfc2543bis,=20
was it decided to limit the inclusion of an SDP to just=20
183 responses? =20

I think that the comment about SDP in section 7.1.5=20
should also be in the sections for 180, 181, and 182.


------=_NextPart_000_0B52_01BFF722.4F69DD70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









During draft-ietf-sip-183-00 incorporation into =
rfc2543bis,=20



was it decided to limit the inclusion of an SDP to =
just=20



183 responses?  


 


I think that the comment about SDP in=20
section 7.1.5 


should also be in the sections for 180, 181, =
and 182.


 


------=_NextPart_000_0B52_01BFF722.4F69DD70--



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


From sip-admin@lists.bell-labs.com  Wed Jul 26 17:08:19 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19578
	for ; Wed, 26 Jul 2000 17:08:19 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 001F644386; Wed, 26 Jul 2000 17:08:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id BEC6044338
	for ; Wed, 26 Jul 2000 17:08:07 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA22075;
	Wed, 26 Jul 2000 17:09:41 -0400 (EDT)
Message-ID: <397F5436.44517D0E@dynamicsoft.com>
Date: Wed, 26 Jul 2000 17:12:22 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brett Tate 
Cc: SIPbell-labs 
Subject: Re: [SIP] rfc2543bis 18x responses with SDP
References: <0b5501bff743$d752f1b0$3102a8c0@broadsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



> Brett Tate wrote:
> 
> During draft-ietf-sip-183-00 incorporation into rfc2543bis,
> was it decided to limit the inclusion of an SDP to just
> 183 responses?

No. Any 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: (732) 741-7244
http://www.dynamicsoft.com


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 17:52:36 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04796
	for ; Wed, 26 Jul 2000 17:52:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ED7214439C; Wed, 26 Jul 2000 17:52:21 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5B90744338
	for ; Wed, 26 Jul 2000 17:52:18 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA22592;
	Wed, 26 Jul 2000 17:53:49 -0400 (EDT)
Message-ID: <397F5E8F.5526CFF1@dynamicsoft.com>
Date: Wed, 26 Jul 2000 17:56:31 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Neil Deason 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Route and maddr
References: <39778379.931BBCA3@cisco.com> <3977DAA1.AA167FF3@dynamicsoft.com> <39782CCE.4BFF8A3E@ubiquity.net> <3978775A.BC475B21@dynamicsoft.com> <39787C95.481C3BDD@ubiquity.net> <397A8F76.BE9DB8AD@dynamicsoft.com> <397C14D0.EE94C286@ubiquity.net> <397E87D5.DE4166C6@dynamicsoft.com> <397EAE00.81DE153E@ubiquity.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Neil Deason wrote:
> 
> > Its not just the maddr copied from the Record-route, it would
> > also be port.
> 
> This would potentially mean building a new SIP URL by
> combining the maddr + port from the one in the Record-Route
> with the other elements of one in the Contact/From. 

Exactly.

> This
> really represents a meaningless SIP URL. This ugliness
> seems to come about beacuse we are overloading the port
> part of the SIP URL in the Record-Route header to
> represent port of a proxy on the route. Is adding a new
> param for the proxy-port not an alternative?

Ugly, yes, but functional and backwards compatible. Adding proxy-port
would not be.

The one wrinkle with this is when you get an incoming request with a tel
URL, and you want to record-route. Now, the tel URL does not have an
maddr or port parameter. So, we may need to define these anyway, for use
in non-sip urls. With sip urls, you would use the URI parameters for
compatibility.
Old proxies won't recognize the new RR parameters, and so they would
rerun the
tel URL routing decision. But, thats what they would do now anyway if
these
parameters weren't there.

> 
> At this point, and pre-IETF/Bakeoff, perhaps it is also
> worth re-raising the issue of a proxy being able to add
> something into the Record-Route to indicate call state.
> This was discussed at the 4th bakeoff but it was pointed
> out using a rr-extension is no use as a proxy wouldn't get
> it back via the Route header as this gets stripped off. If
> there is a real desire to achieve this perhaps something
> added in the name-addr part could work as the proxy should
> get this as part of the incoming Request-URI?

The $10M question is this: if a proxy copies a route header into the
request URI,
does it also copy the URI parameters, even ones it doesn't know about?
What about 
record-route parameters? If the answer to either is yes, that would
provide one
way to accomplish such state pushing, although using State header is
cleaner.

> 
> Finally Jo has pointed out to me that maybe the spec also
> wants to say that a server MUST NOT add itself more than
> once into the Record-Route. Otherwise this could happen on
> a 'legal' loop and the subsequent requests on the call leg
> fail due to an illegal loop being created.

Interesting. This would only happen in the reverse path, since its
only in that case that the request URIs are the same (denoting
a loop as opposed to a spiral). Its a problem,
though, since the proxy really may need to record-route both times.
The solution might be some URI parameter just used as a differentiator.
A different value for this parameter would be inserted in each
Record-Route.
This would be popped into the request URI. Since the request URI is then
different for both, the hashes to compute the branch ID parameter are 
different, and this shows up as a spiral.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 18:06:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08050
	for ; Wed, 26 Jul 2000 18:06:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C0B21443A4; Wed, 26 Jul 2000 18:05:32 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 430B14438D
	for ; Wed, 26 Jul 2000 18:05:29 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA22673;
	Wed, 26 Jul 2000 18:05:43 -0400 (EDT)
Message-ID: <397F6159.2E0AED6D@dynamicsoft.com>
Date: Wed, 26 Jul 2000 18:08:25 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andi Janti 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] how is the proxy talks to the other proxy ?
References: <20000726202932.2965.qmail@web116.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Andi Janti wrote:
> 
> Hi, all
> 
> I'm pretty new on this SIP issue and I was wondering
> how exactly the proxy server talks to other proxy
> server ?

With SIP. The UA to proxy and proxy to proxy protocols are
exactly the same and indistinguishable. Thats a feature.

> A few related questions, if the proxy server that is
> serving the UAC doesn't know the destination address,
> how is the proxy server resolve the called address ?
> Do they need to talk to location server (such as DNS)
> all the way to the top until it finds the address or
> the proxy needs to communicate with another available
> proxy server on the SIP network ?

SIP routing is next-hop routing. It uses some external location
service (whcih can be registrations or anything else you want),
or DNS. 

I recommend you check out the numerous tutorials and papers on sip
available at:
http://www.cs.columbia.edu/~hgs/sip

which explain these basics.

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


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


From sip-admin@lists.bell-labs.com  Wed Jul 26 18:47:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18035
	for ; Wed, 26 Jul 2000 18:47:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B21054439F; Wed, 26 Jul 2000 18:47:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange.NeTrue.com (unknown [207.104.210.242])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 734D144338; Wed, 26 Jul 2000 18:47:13 -0400 (EDT)
Received: by exchange.netrue.com with Internet Mail Service (5.5.2650.21)
	id <3V8FWQFA>; Wed, 26 Jul 2000 15:50:46 -0700
Message-ID: 
From: Tricia Wang 
To: sip@lists.bell-labs.com
Cc: sip@lists.bell-labs.com
Date: Wed, 26 Jul 2000 15:50:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] SIP-SoftSwitch
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

hello

Can SIP inter-working with SoftSwitch ?   are there any drafts or papers
describe how these two inter-working ?

thanks

Tricia 
NeTrue Communications
www.netrue.com
tricia@netrue.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 Jul 26 18:55:35 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19966
	for ; Wed, 26 Jul 2000 18:55:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 19CE8443A6; Wed, 26 Jul 2000 18:55:16 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 0F67244395
	for ; Wed, 26 Jul 2000 18:55:14 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA20909;
	Wed, 26 Jul 2000 18:55:13 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA07783;
	Wed, 26 Jul 2000 18:55:13 -0400 (EDT)
Message-ID: <397F6C51.B907ED4C@cs.columbia.edu>
Date: Wed, 26 Jul 2000 18:55:13 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tricia Wang 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP-SoftSwitch
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

See the SIP FAQ at http://www.cs.columbia.edu/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 Jul 26 18:58:08 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20562
	for ; Wed, 26 Jul 2000 18:58:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5575444398; Wed, 26 Jul 2000 18:58:00 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id D6D0D44338
	for ; Wed, 26 Jul 2000 18:57:56 -0400 (EDT)
Received: from tate ([216.181.56.35]) by broadsoft.com (8.8.8) id SAA42012; Wed, 26 Jul 2000 18:57:44 -0400 (EDT)
Message-ID: <002301bff755$70b47a20$3102a8c0@broadsoft.com>
From: "Brett Tate" 
To: "Tricia Wang" , 
References: 
Subject: Re: [SIP] SIP-SoftSwitch
Date: Wed, 26 Jul 2000 19:01:21 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: Tricia Wang 
To: 
Cc: 
Sent: Wednesday, July 26, 2000 6:50 PM
Subject: [SIP] SIP-SoftSwitch


> hello
> 
> Can SIP inter-working with SoftSwitch ?   are there any drafts or papers
> describe how these two inter-working ?
> 

Yes. 

See http://www.softswitch.org/Protocol/index.html#sip for some drafts.

> thanks
> 
> Tricia 
> NeTrue Communications
> www.netrue.com
> tricia@netrue.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 Jul 27 03:11:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21084
	for ; Thu, 27 Jul 2000 03:11:48 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ED0B94438B; Thu, 27 Jul 2000 03:11:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bbnrel4.net.external.hp.com (bbnrel4.net.external.hp.com [155.208.254.68])
	by lists.bell-labs.com (Postfix) with ESMTP id BAB5B44338
	for ; Thu, 27 Jul 2000 03:11:03 -0400 (EDT)
Received: from mylos.grenoble.hp.com (mylos.grenoble.hp.com [15.128.130.187])
	by bbnrel4.net.external.hp.com (Postfix) with ESMTP id 6EE6911016
	for ; Thu, 27 Jul 2000 09:10:44 +0200 (METDST)
Received: from mylos.grenoble.hp.com (labpc9.grenoble.hp.com [15.128.132.193]) by mylos.grenoble.hp.com with ESMTP (8.7.6/8.7.3 SMKit7.02) id JAA22907; Thu, 27 Jul 2000 09:07:23 +0200 (METDST)
Message-ID: <397FDFAA.8CF8E0A@mylos.grenoble.hp.com>
Date: Thu, 27 Jul 2000 09:07:22 +0200
From: Frederic Huve 
Organization: Hewlett-Packard ( TID)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: SIPbell-labs 
Cc: Magali Genevaux 
Subject: [SIP] SIP-TSI 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi all,

I've heard very interesting sounds around SIP-TSI (Telephony Service
Interface) and Application Server.
Are there any I-Ds or papers available on this topic ? (nothing in the
SIP FAQ...)

Thanks.
--
Frederic HUVE                         5,Avenue Raymond Chanas - Eybens
R&D Engineer                          38053 Grenoble Cedex 9 - FRANCE
Telecom Infrastructure Division       Tel +33 (0)4 76 14 47 43
Hewlett-Packard                       Fax +33 (0)4 76 14 14 88




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


From sip-admin@lists.bell-labs.com  Thu Jul 27 05:25:51 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03702
	for ; Thu, 27 Jul 2000 05:25:51 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3743944395; Thu, 27 Jul 2000 05:25:31 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 5A35744338
	for ; Thu, 27 Jul 2000 05:25:24 -0400 (EDT)
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id OAA01156
	for ; Thu, 27 Jul 2000 14:55:43 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 27 Jul 2000 14:55:41 +0000 (IST)
Received: from pcg140 (pcg140.sasi.com [10.0.64.140])
	by sung17.sasi.com (8.9.3/8.9.3) with SMTP id OAA21154
	for ; Thu, 27 Jul 2000 14:55:40 +0530 (IST)
Message-ID: <037b01bff7ac$3ae84780$8c40000a@sasi.com>
From: "rafi" 
To: 
Date: Thu, 27 Jul 2000 14:52:48 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0378_01BFF7DA.547750A0"
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] Too much time for caching Final response ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_0378_01BFF7DA.547750A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

=20
     Consider the following paragraph in=20
RFC2543 section 10.4.1 which says

" ..After server sends a final response, it
cannot be sure that the client has received
the response, and thus SHOULD cache result
for at least  10*T2  seconds..."

    Thus, when server sends a final response=20
and client did not receive the final response
then server must receive a duplicate request
 from the client  within  T2 seconds. If we assume=20
 that then new request of client is also lost then server
 can  expect  next request within 2*T2 seconds. Thus=20
considering average case, is it always necessary=20
for the server to cache the message  for 10*T2  seconds?.
Can't we go for a lower value?. We should also note that
 timers T1 and T2  are configurable.  When server waits for
 10*T2 second, value of T2 is the timer value of client. There
is no way for the server to access this timer value of client.



Regards
Rafi Assadi H.M.



------=_NextPart_000_0378_01BFF7DA.547750A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 


 


     Consider the =
following=20
paragraph in 


RFC2543 section 10.4.1 which =
says


 


" ..After server sends a final =
response,=20
it


cannot be sure that the client has=20
received


the response, and thus SHOULD cache=20
result


for at least  10*T2 =20
seconds..."


 


    Thus, when server =
sends a final=20
response 


and =
client did not=20
receive the final response


then server must=20
receive a duplicate request


 from the client  within  T2 seconds. If we=20
assume 


 that then new=20
request of client is also =
lost then server


 can =20
expect  next=20
request within 2*T2 seconds. Thus 


considering average=20
case, is it always necessary =



for the server to cache the =
message  for 10*T2 =20
seconds?.


Can't we go for a=20
lower value?. We should also note that


 timers T1 and=20
T2  are configurable.  When server waits for


 10*T2 second,=20
value of T2 is the timer value of client. There


is no way for the server to access this =
timer value=20
of client.


 


 


 


Regards


Rafi Assadi H.M.


 


 


------=_NextPart_000_0378_01BFF7DA.547750A0--



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


From sip-admin@lists.bell-labs.com  Thu Jul 27 08:31:52 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15656
	for ; Thu, 27 Jul 2000 08:31:52 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A83D7443A4; Thu, 27 Jul 2000 08:31:16 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 5FF0F44338
	for ; Thu, 27 Jul 2000 08:31:07 -0400 (EDT)
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id SAA09034
	for ; Thu, 27 Jul 2000 18:01:25 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 27 Jul 2000 18:01:24 +0000 (IST)
Received: from pcg140 (pcg140.sasi.com [10.0.64.140])
	by sung17.sasi.com (8.9.3/8.9.3) with SMTP id SAA24076
	for ; Thu, 27 Jul 2000 18:01:25 +0530 (IST)
Message-ID: <03ec01bff7c6$2c9041a0$8c40000a@sasi.com>
From: "rafi" 
To: 
Date: Thu, 27 Jul 2000 17:58:31 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_03E9_01BFF7F4.461DC420"
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] Record-Roue & Contact Headers
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_03E9_01BFF7F4.461DC420
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

   Consider the following scenario using
Record-Route and Contact header field.

A              Proxy-1      Contact Server       B

   INVITE
 ---------------->
                    INVITE(Record-Route:Proxy-1)
                    -------------------------------->

                       200 OK ( Record-Route  :Prxoy-1,
                                     Contact : Contact-Server )
                    <---------------------------------
 =20
  200 OK( Record-Route  :Prxoy-1
               Contact : Contact-Server)
  <------------


ACK (Route :Contact-Server)
 ---------------------->

                             ACK
                       ------------------>

                              ACK
                       <------------------- (Loop here)

                       482 (Loop Detected)
                       ------------------>

   ???
<--------------------


   In the above scenario, Contact server uses proxy-1 in order to send
request. Thus when A uses Record-Route together with Contact URL
in order to construct Route Header field there may be potential chance=20
that  loop may be created. Thus, when proxy detects this how can it=20
inform A (UAC) about this condition ?. I have given a bad example but
 imagine this case when call passes through many proxy and contact
 server uses one of the proxy in the call leg to send further request. =
It is
 however true that Contact server itself can detect loop  but it is not
clear how UAC knows about these fact and avoid it in future.

Regards
Rafi Assadi H.M


------=_NextPart_000_03E9_01BFF7F4.461DC420
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi,


 


   Consider the following =
scenario=20
using
Record-Route and Contact header field.



A          &nb=
sp;  =20
Proxy-1      Contact=20
Server       B


 


  =20
INVITE
 ---------------->
     &nb=
sp;           &nbs=
p; =20
INVITE(Record-Route:Proxy-1)
       =
;            =
=20
-------------------------------->


 


          &nbs=
p;           =20
200 OK ( Record-Route =20
:Prxoy-1,
          =
            &=
nbsp;           &n=
bsp; =20
Contact : Contact-Server=20
)
           &n=
bsp;       =20
<---------------------------------
  
  200 OK(=20
Record-Route  :Prxoy-1


          &nbs=
p;   =20
Contact : Contact-Server)


  <------------


 



ACK (Route=20
:Contact-Server)
 ---------------------->


 


          &nbs=
p;            =
;     =20
ACK
           =
           =20
------------------>


 


          &nbs=
p;            =
;      =20
ACK
           =
           =20
<------------------- (Loop here)


 


          &nbs=
p;           =20
482 (Loop=20
Detected)
          =
             =

------------------>


 


  =20
???
<--------------------


 



   In the above scenario, =
Contact=20
server uses proxy-1 in order to send
request. Thus when A uses =
Record-Route=20
together with Contact URL
in order to construct Route Header field =
there may=20
be potential chance 


that  loop may be created. Thus, =
when proxy=20
detects this how can it 


inform A (UAC) about this =
condition ?. I have=20
given a bad example but


 imagine this case when call =
passes through=20
many proxy and contact


 server uses one of the proxy in =
the call leg=20
to send further request. It is


 however true that Contact server =
itself can=20
detect loop  but it is not
clear how UAC knows about these fact =
and=20
avoid it in future.


 


Regards
Rafi Assadi=20
H.M


------=_NextPart_000_03E9_01BFF7F4.461DC420--



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


From sip-admin@lists.bell-labs.com  Thu Jul 27 09:11:57 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21652
	for ; Thu, 27 Jul 2000 09:11:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5BE4A443A4; Thu, 27 Jul 2000 09:11:35 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id EA57844338
	for ; Thu, 27 Jul 2000 09:11:30 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id OAA03514; Thu, 27 Jul 2000 14:08:57 +0100 (BST)
From: "Jo Hornsby" 
To: "Henning Schulzrinne" ,
        "Jonathan Rosenberg" 
Cc: 
Subject: RE: [SIP] ACK handling at Stateful Proxies
Date: Thu, 27 Jul 2000 14:08:56 +0100
Message-ID: <002101bff7cb$d245e140$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <397F33A6.E874C0C3@cs.columbia.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> I simplified section 12.3.5 to read
> 
> When an {\ACK} request is received, it is proxied unless the request's
> \header{To} (including the tag), \header{From}, \header{CSeq} and
> \header{Call-ID} header fields match those of a (non-200) response sent
> by the proxy.  In that case, the request is processed locally and stops
> retransmissions of responses.
> 
> I believe that handles the multiple-ACK case and is simpler. It does
> require that a server keep track of which non-2xx response it has
> forwarded, since it needs to match the To tag.
> 
> Let me know if I missed any tag subtleties...

My original (badly explained) point was that in the case of a
re-INVITE, you wouldn't be able to distinguish between an ACK
for the non-2xx response that the proxy returned (or forwarded),
and an ACK for a "late" 200 (that the proxy also had to forward).

This is because the re-INVITE would already have a tag in the
To header, so a proxy would be unable to play with it.

I was going to suggest that in this case, the proxy both forward
the ACK and process it locally, but I've just realised that
that might halt 2xx retransmissions when the UAC hadn't even
seen the 2xx.

Given this, I think that the new 12.3.5 above is the best that
we can do.

Ah well. &:)

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 Jul 27 09:16:20 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22389
	for ; Thu, 27 Jul 2000 09:16:20 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 50B10443A8; Thu, 27 Jul 2000 09:15:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 47D234439E
	for ; Thu, 27 Jul 2000 09:15:49 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA21508;
	Thu, 27 Jul 2000 09:15:48 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA22165;
	Thu, 27 Jul 2000 09:15:48 -0400 (EDT)
Message-ID: <39803604.710D0AB8@cs.columbia.edu>
Date: Thu, 27 Jul 2000 09:15:48 -0400
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jo Hornsby 
Cc: Jonathan Rosenberg , sip@lists.bell-labs.com
Subject: Re: [SIP] ACK handling at Stateful Proxies
References: <002101bff7cb$d245e140$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Jo Hornsby wrote:
> 
> > I simplified section 12.3.5 to read
> >
> > When an {\ACK} request is received, it is proxied unless the request's
> > \header{To} (including the tag), \header{From}, \header{CSeq} and
> > \header{Call-ID} header fields match those of a (non-200) response sent
> > by the proxy.  In that case, the request is processed locally and stops
> > retransmissions of responses.
> >
> > I believe that handles the multiple-ACK case and is simpler. It does
> > require that a server keep track of which non-2xx response it has
> > forwarded, since it needs to match the To tag.
> >
> > Let me know if I missed any tag subtleties...
> 
> My original (badly explained) point was that in the case of a
> re-INVITE, you wouldn't be able to distinguish between an ACK
> for the non-2xx response that the proxy returned (or forwarded),
> and an ACK for a "late" 200 (that the proxy also had to forward).
> 
> This is because the re-INVITE would already have a tag in the
> To header, so a proxy would be unable to play with it.

Pardon me for deing dense, but the proxy never adds a tag. It forwards
the responses from one of the branches. Unless a single To;tag
combination produces both a 200 and a 3/4/5/6xx (which it should never
do), it should be unambiguous which response the ACK belongs to. The
proxy would track whether it had issued a non-200 for this To;tag and
decide accordingly.


> 
> I was going to suggest that in this case, the proxy both forward
> the ACK and process it locally, but I've just realised that
> that might halt 2xx retransmissions when the UAC hadn't even
> seen the 2xx.
> 
> Given this, I think that the new 12.3.5 above is the best that
> we can do.
> 
> Ah well. &:)
> 
> Cheers,
> 
>  - Jo.

-- 
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 Jul 27 09:36:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25023
	for ; Thu, 27 Jul 2000 09:36:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0395C443B1; Thu, 27 Jul 2000 09:35:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 3D1D544386
	for ; Thu, 27 Jul 2000 09:35:25 -0400 (EDT)
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id TAA11544
	for ; Thu, 27 Jul 2000 19:05:43 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 27 Jul 2000 19:05:42 +0000 (IST)
Received: from pcg140 (pcg140.sasi.com [10.0.64.140])
	by sung17.sasi.com (8.9.3/8.9.3) with SMTP id TAA24884
	for ; Thu, 27 Jul 2000 19:05:41 +0530 (IST)
Message-ID: <043901bff7cf$27a9e5c0$8c40000a@sasi.com>
From: "rafi" 
To: 
Date: Thu, 27 Jul 2000 19:02:48 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0436_01BFF7FD.4138EEE0"
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] Is this true ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_0436_01BFF7FD.4138EEE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

   If a proxy forwards multiple
200 OK response then is it not=20
necessary for the prxoy to be in
 the call leg untill call is terminated?

Regards
Rafi Assadi H.M.



------=_NextPart_000_0436_01BFF7FD.4138EEE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi,


 


   If a proxy forwards=20
multiple


200 OK response then is it not =



necessary for the=20
prxoy to be in


 the call leg untill call is terminated?


 


Regards


Rafi Assadi H.M.


 


 


------=_NextPart_000_0436_01BFF7FD.4138EEE0--



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


From sip-admin@lists.bell-labs.com  Thu Jul 27 10:16:53 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00381
	for ; Thu, 27 Jul 2000 10:16:52 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 881E8443AF; Thu, 27 Jul 2000 10:16:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D5B7244338
	for ; Thu, 27 Jul 2000 10:16:02 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA25131;
	Thu, 27 Jul 2000 10:17:23 -0400 (EDT)
Message-ID: <3980451A.FC62475F@dynamicsoft.com>
Date: Thu, 27 Jul 2000 10:20:10 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rafi 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Is this true ?
References: <043901bff7cf$27a9e5c0$8c40000a@sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Proxies never need to be on the signaling path after the first INVITE.
Whether they are will depend on whether they have record routed,
independently of whether there was one or multiple 200 OK (they will be
on the path for all of the signaling legs).

-Jonathan R.

> rafi wrote:
> 
> Hi,
> 
>    If a proxy forwards multiple
> 200 OK response then is it not
> necessary for the prxoy to be in
>  the call leg untill call is terminated?
> 
> Regards
> Rafi Assadi H.M.
> 
> 

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


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


From sip-admin@lists.bell-labs.com  Thu Jul 27 10:22:51 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02027
	for ; Thu, 27 Jul 2000 10:22:51 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E2F71443B7; Thu, 27 Jul 2000 10:22:18 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8D6F8443B2
	for ; Thu, 27 Jul 2000 10:22:14 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA25228;
	Thu, 27 Jul 2000 10:23:41 -0400 (EDT)
Message-ID: <39804694.E7D899A8@dynamicsoft.com>
Date: Thu, 27 Jul 2000 10:26:28 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rafi 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Roue & Contact Headers
References: <03ec01bff7c6$2c9041a0$8c40000a@sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

This call flow makes no sense. B appears to be a UAS. Why would it
randomly generate an ACK upon receiving
an ACK? Also, ACKs are NEVER responded to.

-Jonathan R.


> rafi wrote:
> 
> Hi,
> 
>    Consider the following scenario using
> Record-Route and Contact header field.
> 
> A              Proxy-1      Contact Server       B
> 
>    INVITE
>  ---------------->
>                     INVITE(Record-Route:Proxy-1)
>                     -------------------------------->
> 
>                        200 OK ( Record-Route  :Prxoy-1,
>                                      Contact : Contact-Server )
>                     <---------------------------------
> 
>   200 OK( Record-Route  :Prxoy-1
>                Contact : Contact-Server)
>   <------------
> 
> 
> ACK (Route :Contact-Server)
>  ---------------------->
> 
>                              ACK
>                        ------------------>
> 
>                               ACK
>                        <------------------- (Loop here)
> 
>                        482 (Loop Detected)
>                        ------------------>
> 
>    ???
> <--------------------
> 
> 
>    In the above scenario, Contact server uses proxy-1 in order to send
> request. Thus when A uses Record-Route together with Contact URL
> in order to construct Route Header field there may be potential chance
> that  loop may be created. Thus, when proxy detects this how can it
> inform A (UAC) about this condition ?. I have given a bad example but
>  imagine this case when call passes through many proxy and contact
>  server uses one of the proxy in the call leg to send further request.
> It is
>  however true that Contact server itself can detect loop  but it is
> not
> clear how UAC knows about these fact and avoid it in future.
> 
> Regards
> Rafi Assadi H.M

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


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


From sip-admin@lists.bell-labs.com  Thu Jul 27 10:31:57 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05017
	for ; Thu, 27 Jul 2000 10:31:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DFAEA443BC; Thu, 27 Jul 2000 10:31:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id BA3C044338
	for ; Thu, 27 Jul 2000 10:30:46 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA10448; Thu, 27 Jul 2000 15:27:40 +0100 (BST)
From: "Jo Hornsby" 
To: "Henning Schulzrinne" 
Cc: "Jonathan Rosenberg" , 
Subject: RE: [SIP] ACK handling at Stateful Proxies
Date: Thu, 27 Jul 2000 15:27:40 +0100
Message-ID: <002401bff7d6$d1a61dd0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <39803604.710D0AB8@cs.columbia.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> > My original (badly explained) point was that in the case of a
> > re-INVITE, you wouldn't be able to distinguish between an ACK
> > for the non-2xx response that the proxy returned (or forwarded),
> > and an ACK for a "late" 200 (that the proxy also had to forward).
> > 
> > This is because the re-INVITE would already have a tag in the
> > To header, so a proxy would be unable to play with it.
> 
> Pardon me for deing dense, but the proxy never adds a tag.

Sorry -- "play" was a bad word to use.

> It forwards
> the responses from one of the branches.

Yes.  But there are also cases where the response is generated
locally: 404, 408 being typical examples.

> Unless a single To;tag
> combination produces both a 200 and a 3/4/5/6xx (which it should never
> do), it should be unambiguous which response the ACK belongs to. The
> proxy would track whether it had issued a non-200 for this To;tag and
> decide accordingly.

It is unlikely, but I don't think that is so impossible.

Consider that two UAs are in an (audio) call.  The caller decides
that they would like to add video.  The callee's UA interactively
asks the callee if it's okay to add the video stream.  The callee
is temporarily distracted, and does not initially see the prompt.
An intermediate proxy times out, returns a 408 and sends a CANCEL
downstream.  Meanwhile the callee has accepted the video and the
callee's UA returns 200 before it sees the CANCEL.  The timed-out
(and any other) proxies have to forward the 200, so the caller's
UA sees both a 408 and a 200 (note that it is not necessarily
obvious which order these will arrive in).

At any point along the route, it will not be apparent to a proxy
whether the ACK is for the 408 or for the 200.

With the new wording, the 200 will probably not be ACKed; I think
that this is the preferable behaviour since the 408 is more likely
to be seen at the callee's UA before the 200, and I would guess
that the 200 will just be seen as a retransmission of the 408.
Therefore both UAs will conclude the same thing: that the re-INVITE
failed.

I'm happy now. &:)
Have I missed anything?


 - 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 Jul 27 10:53:11 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10094
	for ; Thu, 27 Jul 2000 10:53:10 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 37A8D4439E; Thu, 27 Jul 2000 10:53:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 1A6A244338
	for ; Thu, 27 Jul 2000 10:52:58 -0400 (EDT)
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id UAA14258;
	Thu, 27 Jul 2000 20:23:12 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 27 Jul 2000 20:23:12 +0000 (IST)
Received: from pcg140 (pcg140.sasi.com [10.0.64.140])
	by sung17.sasi.com (8.9.3/8.9.3) with SMTP id UAA25576;
	Thu, 27 Jul 2000 20:23:11 +0530 (IST)
Message-ID: <056801bff7d9$faaf0040$8c40000a@sasi.com>
From: "rafi" 
To: "Jonathan Rosenberg" 
Cc: 
References: <03ec01bff7c6$2c9041a0$8c40000a@sasi.com> <39804694.E7D899A8@dynamicsoft.com>
Subject: Re: [SIP] Record-Roue & Contact Headers
Date: Thu, 27 Jul 2000 20:20:17 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

  Pardon me, there was a small mistake in call flow,
please have a look at new call flow.

  To clarify thing further when A  wants to send
ACK message it construct the route using Record-Route
and Contact header fileds, thus Route is via proxy-1 and 
Contact server. When proxy-1 sends ACK to Contact server
then Contact server forwards it again to proxy-1 
due to some configuration at Contact server.

Thanks
Rafi Assadi H.M.


A              Proxy-1      Contact Server              B
INVITE
---------------->
INVITE(Record-Route:Proxy-1)
                    ------------------------------------>
 
                        200 OK ( Record-Route  :Prxoy-1,
                                      Contact : Contact-Server )
                     <-----------------------------------
 
   200 OK( Record-Route  :Prxoy-1
                Contact : Contact-Server)
   <------------
 
 
 ACK (Route :Contact-Server)
  ---------------------->
 
                              ACK
                        ---------------> 
                              ACK
                        <------------- (Loop here)
 
                        482 (Loop Detected)
                        ---------------->
 
   ???
 <----------------
 


----- Original Message ----- 
From: Jonathan Rosenberg 
To: rafi 
Cc: 
Sent: Thursday, July 27, 2000 7:56 PM
Subject: Re: [SIP] Record-Roue & Contact Headers


> This call flow makes no sense. B appears to be a UAS. Why would it
> randomly generate an ACK upon receiving
> an ACK? Also, ACKs are NEVER responded to.
> 
> -Jonathan R.
> 
> 
> > rafi wrote:
> > 
> > Hi,
> > 
> >    Consider the following scenario using
> > Record-Route and Contact header field.
> > 
> > A              Proxy-1      Contact Server       B
> > 
> >    INVITE
> >  ---------------->
> >                     INVITE(Record-Route:Proxy-1)
> >                     -------------------------------->
> > 
> >                        200 OK ( Record-Route  :Prxoy-1,
> >                                      Contact : Contact-Server )
> >                     <---------------------------------
> > 
> >   200 OK( Record-Route  :Prxoy-1
> >                Contact : Contact-Server)
> >   <------------
> > 
> > 
> > ACK (Route :Contact-Server)
> >  ---------------------->
> > 
> >                              ACK
> >                        ------------------>
> > 
> >                               ACK
> >                        <------------------- (Loop here)
> > 
> >                        482 (Loop Detected)
> >                        ------------------>
> > 
> >    ???
> > <--------------------
> > 
> > 
> >    In the above scenario, Contact server uses proxy-1 in order to send
> > request. Thus when A uses Record-Route together with Contact URL
> > in order to construct Route Header field there may be potential chance
> > that  loop may be created. Thus, when proxy detects this how can it
> > inform A (UAC) about this condition ?. I have given a bad example but
> >  imagine this case when call passes through many proxy and contact
> >  server uses one of the proxy in the call leg to send further request.
> > It is
> >  however true that Contact server itself can detect loop  but it is
> > not
> > clear how UAC knows about these fact and avoid it in future.
> > 
> > Regards
> > Rafi Assadi H.M
> 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com



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


From sip-admin@lists.bell-labs.com  Thu Jul 27 10:55:17 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10544
	for ; Thu, 27 Jul 2000 10:55:16 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EDB36443C4; Thu, 27 Jul 2000 10:53:48 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 869E6443BE
	for ; Thu, 27 Jul 2000 10:53:41 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA25651;
	Thu, 27 Jul 2000 10:54:47 -0400 (EDT)
Message-ID: <39804DDD.3C6072D5@dynamicsoft.com>
Date: Thu, 27 Jul 2000 10:57:33 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jo Hornsby 
Cc: Henning Schulzrinne , sip@lists.bell-labs.com
Subject: Re: [SIP] ACK handling at Stateful Proxies
References: <002401bff7d6$d1a61dd0$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jo Hornsby wrote:
> 
> > Unless a single To;tag
> > combination produces both a 200 and a 3/4/5/6xx (which it should never
> > do), it should be unambiguous which response the ACK belongs to. The
> > proxy would track whether it had issued a non-200 for this To;tag and
> > decide accordingly.
> 
> It is unlikely, but I don't think that is so impossible.
> 
> Consider that two UAs are in an (audio) call.  The caller decides
> that they would like to add video.  The callee's UA interactively
> asks the callee if it's okay to add the video stream.  The callee
> is temporarily distracted, and does not initially see the prompt.
> An intermediate proxy times out, returns a 408 and sends a CANCEL
> downstream.  Meanwhile the callee has accepted the video and the
> callee's UA returns 200 before it sees the CANCEL.  The timed-out
> (and any other) proxies have to forward the 200, so the caller's
> UA sees both a 408 and a 200 (note that it is not necessarily
> obvious which order these will arrive in).

I'll note that this won't happen in the proxy uses the new CANCEL rules
(the 487 stuff). In that case, it won't send a response after CANCEL, it
will wait to receive the 487 and then forward that. 

The other case which can cause multiple responses is forking, but
reinvites
will, with the bis draft, never be forked. Thats because the UAS inserts
a Contact into the 200 OK. Reinvites thus always have a route directly
to the UAS.

So, in practice, this problem will go away once everyone has implemented
the bis
draft. In the interim, it can happen. In this case, I would recommend
forwarding
ACKs that match a 200 OK you've sent upstream.

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


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


From sip-admin@lists.bell-labs.com  Thu Jul 27 11:03:51 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12492
	for ; Thu, 27 Jul 2000 11:03:51 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 453F2443C8; Thu, 27 Jul 2000 11:02:56 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 4C047443C0
	for ; Thu, 27 Jul 2000 11:02:52 -0400 (EDT)
Received: (qmail 3592 invoked by uid 1002); 27 Jul 2000 14:58:40 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 27 Jul 2000 17:58:37 +0300 (IDT)
To: "rafi" 
Cc: SIP 
Subject: [SIP] Record-Roue & Contact Headers
In-Reply-To: <03ec01bff7c6$2c9041a0$8c40000a@sasi.com>
References: <03ec01bff7c6$2c9041a0$8c40000a@sasi.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14720.19607.684672.825238@jodie.lucid>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

rafi writes ("[SIP] Record-Roue & Contact Headers"):

>                              ACK
>                        ------------------>
>                               ACK
>                        <------------------- (Loop here)
>                        482 (Loop Detected)
>                        ------------------>

Actually, I think the loop would be detected before the looped ACK is
sent, since each proxy has to verify that it is not sending a request
to a UA in the Via, though the proxy, in the above example, is
allready in the Via, thus the loop is detected earlier.

Also, I don't think that you should send any response after getting an 
ACK.  Responses are for INVITEs and BYEs (well, actually, anything but 
ACKs).  What the UA detecting the loop should probably do is initiate
a hangup at this point.

More to your point, though, I wouldn't suggest putting a Contact of a
proxy.  I know the RFC says something about allowing to put a Contact
of a proxy, but this seems unneeded.  If the proxy wants to be in the
route, it should add itself in the Record-Route.  It is true that if
the UAC adds a Contact of some proxy already in the middle, it will
cause a loop.

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Thu Jul 27 11:24:32 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17392
	for ; Thu, 27 Jul 2000 11:24:31 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7ACD7443BF; Thu, 27 Jul 2000 11:24:29 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C3A3C44338
	for ; Thu, 27 Jul 2000 11:24:25 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA26088;
	Thu, 27 Jul 2000 11:25:49 -0400 (EDT)
Message-ID: <39805524.AB0937F0@dynamicsoft.com>
Date: Thu, 27 Jul 2000 11:28:36 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rafi 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Roue & Contact Headers
References: <03ec01bff7c6$2c9041a0$8c40000a@sasi.com> <39804694.E7D899A8@dynamicsoft.com> <056801bff7d9$faaf0040$8c40000a@sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



rafi wrote:
> 
> Hi,
> 
>   Pardon me, there was a small mistake in call flow,
> please have a look at new call flow.
> 
>   To clarify thing further when A  wants to send
> ACK message it construct the route using Record-Route
> and Contact header fileds, thus Route is via proxy-1 and
> Contact server. When proxy-1 sends ACK to Contact server
> then Contact server forwards it again to proxy-1
> due to some configuration at Contact server.

Why would it do that? It responded to the INVITE to begin with, so
why would it now forward the ACK? 

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Thu Jul 27 11:34:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20406
	for ; Thu, 27 Jul 2000 11:34:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 705C6443BA; Thu, 27 Jul 2000 11:33:53 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 3B769443A8
	for ; Thu, 27 Jul 2000 11:33:47 -0400 (EDT)
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id VAA15443;
	Thu, 27 Jul 2000 21:04:06 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Thu, 27 Jul 2000 21:04:05 +0000 (IST)
Received: from pcg140 (pcg140.sasi.com [10.0.64.140])
	by sung17.sasi.com (8.9.3/8.9.3) with SMTP id VAA25909;
	Thu, 27 Jul 2000 21:04:04 +0530 (IST)
Message-ID: <05b301bff7df$b0bce3c0$8c40000a@sasi.com>
From: "rafi" 
To: "Jonathan Rosenberg" 
Cc: 
References: <03ec01bff7c6$2c9041a0$8c40000a@sasi.com> <39804694.E7D899A8@dynamicsoft.com> <056801bff7d9$faaf0040$8c40000a@sasi.com> <39805524.AB0937F0@dynamicsoft.com>
Subject: Re: [SIP] Record-Roue & Contact Headers
Date: Thu, 27 Jul 2000 21:01:10 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi,

   May be the example I have taken is 
too primitive. What I want to convey is
something like this 

Route = Record-Route + Contact Header

Now,  if  the server mentioned in the Contact Header
uses one of the proxy in the Record-Route Header
then it will cause loop. Please note that when 
client  includes contact Address in response 
it MAY not know how Contact Server delivers 
the  SIP message.

Thank You
Rafi Assadi H.M.


----- Original Message ----- 
From: Jonathan Rosenberg 
To: rafi 
Cc: 
Sent: Thursday, July 27, 2000 8:58 PM
Subject: Re: [SIP] Record-Roue & Contact Headers


> 
> 
> rafi wrote:
> > 
> > Hi,
> > 
> >   Pardon me, there was a small mistake in call flow,
> > please have a look at new call flow.
> > 
> >   To clarify thing further when A  wants to send
> > ACK message it construct the route using Record-Route
> > and Contact header fileds, thus Route is via proxy-1 and
> > Contact server. When proxy-1 sends ACK to Contact server
> > then Contact server forwards it again to proxy-1
> > due to some configuration at Contact server.
> 
> Why would it do that? It responded to the INVITE to begin with, so
> why would it now forward the ACK? 
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com



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


From sip-admin@lists.bell-labs.com  Thu Jul 27 13:23:49 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08027
	for ; Thu, 27 Jul 2000 13:23:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B4C2F443B8; Thu, 27 Jul 2000 13:23:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D413C44338
	for ; Thu, 27 Jul 2000 13:23:42 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA27355
	for ; Thu, 27 Jul 2000 13:25:17 -0400 (EDT)
Message-ID: <39807123.F6C7F1A6@dynamicsoft.com>
Date: Thu, 27 Jul 2000 13:28:03 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Scheduling of "bar bofs"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Folks,

The following informal gatherings are taking place at IETF:

1. discussion of multiparty conferencing
   10pm, Monday, place TBD

2. discussion of event notifications and subscriptions
   9pm, Wednesday, place TBD

3. security taskforce
   11:30am - 1pm (lunch) Thursday, place TBD


I figured the security taskfoce should meet again; all are welcome as
always. I'll be announcing the place once I figure it out. Likely the
two evening ones will be in someones hotel room (actually, if you are
attending either and are staying in the DoubleTree and would volunteer
your room as a meeting place, let mw know) or a bar in a hotel, and the
security taskforce at a restaurant.

Please let me know if you are going to come.

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: (732) 741-7244
http://www.dynamicsoft.com


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


From sip-admin@lists.bell-labs.com  Thu Jul 27 14:28:11 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19235
	for ; Thu, 27 Jul 2000 14:28:10 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6E6A94436D; Thu, 27 Jul 2000 14:28:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 9F93F44338
	for ; Thu, 27 Jul 2000 14:28:02 -0400 (EDT)
Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA23579
	for ; Thu, 27 Jul 2000 11:28:16 -0700 (PDT)
Received: from cisco.com ([171.71.159.231])
	by driftwood.cisco.com (Mirapoint)
	with ESMTP id ABJ01993;
	Thu, 27 Jul 2000 13:24:52 -0500 (CDT)
Message-ID: <39807F7B.868F8E02@cisco.com>
Date: Thu, 27 Jul 2000 13:29:15 -0500
From: Hong Chen 
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Call Park abd Call Pickup
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I need helps to understand how to implement CALL Park and Call Pickup
features
by SIP?

Thanks,

Henry



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


From sip-admin@lists.bell-labs.com  Fri Jul 28 01:51:49 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25349
	for ; Fri, 28 Jul 2000 01:51:48 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 426AF4439E; Fri, 28 Jul 2000 01:51:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1143F44337
	for ; Fri, 28 Jul 2000 01:51:07 -0400 (EDT)
Received: from dynamicsoft.com (1Cust16.tnt3.freehold.nj.da.uu.net [63.25.172.16])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01231;
	Fri, 28 Jul 2000 01:42:49 -0400 (EDT)
Message-ID: <39811E01.76069CAB@dynamicsoft.com>
Date: Fri, 28 Jul 2000 01:45:37 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rafi 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Record-Roue & Contact Headers
References: <03ec01bff7c6$2c9041a0$8c40000a@sasi.com> <39804694.E7D899A8@dynamicsoft.com> <056801bff7d9$faaf0040$8c40000a@sasi.com> <39805524.AB0937F0@dynamicsoft.com> <05b301bff7df$b0bce3c0$8c40000a@sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



rafi wrote:
> 
> Hi,
> 
>    May be the example I have taken is
> too primitive. What I want to convey is
> something like this
> 
> Route = Record-Route + Contact Header
> 
> Now,  if  the server mentioned in the Contact Header
> uses one of the proxy in the Record-Route Header
> then it will cause loop.

This still makes no sense. The UAS listed in the Contact header
is a UAS. When it receives a request, it doesn't proxy it.
If it did, it would be a proxy.

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 28 01:53:36 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26254
	for ; Fri, 28 Jul 2000 01:53:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 44028443A8; Fri, 28 Jul 2000 01:53:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 6379C44395
	for ; Fri, 28 Jul 2000 01:53:02 -0400 (EDT)
Received: from dynamicsoft.com (1Cust16.tnt3.freehold.nj.da.uu.net [63.25.172.16])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01239;
	Fri, 28 Jul 2000 01:48:18 -0400 (EDT)
Message-ID: <39811F4B.A918769A@dynamicsoft.com>
Date: Fri, 28 Jul 2000 01:51:07 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rafi 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Too much time for caching Final response ?
References: <037b01bff7ac$3ae84780$8c40000a@sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



> rafi wrote:
> 
> Hi,
> 
> 
>      Consider the following paragraph in
> RFC2543 section 10.4.1 which says
> 
> " ..After server sends a final response, it
> cannot be sure that the client has received
> the response, and thus SHOULD cache result
> for at least  10*T2  seconds..."
> 
>     Thus, when server sends a final response
> and client did not receive the final response
> then server must receive a duplicate request
>  from the client  within  T2 seconds. 

Not if that request is lost. 10 represents a number slightly
larger than the number of restransmissions of requests
the client would make before giving up.

> We should also note that
>  timers T1 and T2  are configurable.  When server waits for
>  10*T2 second, value of T2 is the timer value of client. There
> is no way for the server to access this timer value of client.

No big deal. This is a cache. You can always reconstruct 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: (732) 741-7244
http://www.dynamicsoft.com


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


From sip-admin@lists.bell-labs.com  Fri Jul 28 02: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 ESMTP id CAA04365
	for ; Fri, 28 Jul 2000 02:03:26 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 54E34443B9; Fri, 28 Jul 2000 02:02:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 65DE444343
	for ; Fri, 28 Jul 2000 02:02:41 -0400 (EDT)
Received: from dynamicsoft.com (1Cust16.tnt3.freehold.nj.da.uu.net [63.25.172.16])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA01351;
	Fri, 28 Jul 2000 02:04:13 -0400 (EDT)
Message-ID: <39812305.C362D6B@dynamicsoft.com>
Date: Fri, 28 Jul 2000 02:07:01 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rohan Mahy 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Session header
References: <4.2.0.58.20000721113819.00d92a10@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-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

The authors of the 183 draft discussed this and we came to the following
conclusion:

1. The Session header would be eliminated, rather its values would be
folded in as a parameter of the Content-Disposition header.
2. These parameters would be defined in the rfc2543bis draft.

Since the header is optional, and since it is such a small thing and
related to Content-Disposition anyway, folding it into the bis draft
seemed best.

Comments?

-Jonathan R.

Rohan Mahy wrote:
> 
> Hi,
> 
> The Session header was defined originally in the 183 draft.  Now that the
> 183 has expired (?), the 183 response has moved into the bis draft, but the
> Session header has not. Can we still move the Session header into the bis
> draft?
> 
> thanks,
> -rohan
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 28 02:15: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 ESMTP id CAA11931
	for ; Fri, 28 Jul 2000 02:15:54 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 753B1443B5; Fri, 28 Jul 2000 02:15:50 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2])
	by lists.bell-labs.com (Postfix) with ESMTP id E73E0443A2
	for ; Fri, 28 Jul 2000 02:15:43 -0400 (EDT)
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id LAA05854
	for ; Fri, 28 Jul 2000 11:46:04 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Fri, 28 Jul 2000 11:46:01 +0000 (IST)
Received: from pcg140 (pcg140.sasi.com [10.0.64.140])
	by sung17.sasi.com (8.9.3/8.9.3) with SMTP id LAA02530
	for ; Fri, 28 Jul 2000 11:45:40 +0530 (IST)
Message-ID: <068f01bff85a$d5ad1b20$8c40000a@sasi.com>
From: "rafi" 
To: 
Date: Fri, 28 Jul 2000 11:42:40 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_068C_01BFF888.EF3A9DA0"
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] ACK received after crash
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

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


Consider the following call scenario,


A                                  B


               INVITE

   ----------------------------------->

               200 OK
  <-----------------------------------

                          Server Crashes here

                           Server Comes Up

            ACK
  -------------------------------->
                                        =20
                     Finds call id is invalid
                     and discards the ACK silently



 Thus in the above call scenario, A is under the impression
that call is through but actually call is not established end to end.=20
One could argue that when user at A actually start using media=20
he may not hear  anything from other end and MAY release the
call. Thus in general  how A  detect this and release the call as=20
soon as possible ?

Thank You
Rafi Assadi H.M.


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









 


Consider the following call =
scenario,


 



A          =
;            =
           =20
B


 



          =
    =20
INVITE


 


 =20
 ----------------------------------->


 


          &nbs=
p;   =20
200 OK
  <-----------------------------------


 


          &nbs=
p;            =
; =20
 Server Crashes here


 


          &nbs=
p;            =
;   =20
Server Comes Up


 


          &nbs=
p;=20
ACK
 =20
-------------------------------->
     &nb=
sp;           &nbs=
p;            =
;           
&n=
bsp;           &nb=
sp;        Finds=20
call id is=20
invalid
          &n=
bsp;         =20
and discards the ACK silently


 


 


 


 Thus in the above call scenario, =
A is under=20
the impression
that call is through but actually call is not =
established end=20
to end. 


One could argue that when user at A =
actually start=20
using media 


he may not hear  anything from =
other end and=20
MAY release the


call. Thus in general  how A  =
detect this=20
and release the call as 


soon as possible ?


 


Thank You
Rafi Assadi=20
H.M.


------=_NextPart_000_068C_01BFF888.EF3A9DA0--



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


From sip-admin@lists.bell-labs.com  Fri Jul 28 02:35:35 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18510
	for ; Fri, 28 Jul 2000 02:35:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 805EE443C5; Fri, 28 Jul 2000 02:34:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D36A944337
	for ; Fri, 28 Jul 2000 02:34:48 -0400 (EDT)
Received: from dynamicsoft.com (1Cust16.tnt3.freehold.nj.da.uu.net [63.25.172.16])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA01394;
	Fri, 28 Jul 2000 02:35:53 -0400 (EDT)
Message-ID: <39812A72.3ED81E42@dynamicsoft.com>
Date: Fri, 28 Jul 2000 02:38:42 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alex Hardisty 
Cc: Henning Schulzrinne , brett@broadsoft.com,
        sip@lists.bell-labs.com
Subject: Re: [SIP] rfc2543bis: table 4 comments
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I actually think SHOULD is 'o' as opposed to 'm'. As Alex points out,
for backwards compatibility you will need to handle the case of not
getting a Content-Length.

-Jonathan R.

Alex Hardisty wrote:
> 
> Brett Tate wrote:
> 
> > Row "Content-Length" should be all "o" if the last two
> > paragraphs in section 6.19 are correct.
> 
> Henning Schulzrinne wrote:
> 
> > It says "SHOULD" for Content-Length, so this is probably closer to 'm'
> > than 'o'.
> 
> My interpretation of the text "as written" is that it is (according to table
> 4) mandatory to include the Content-Length in all Methods. The last two
> paragraphs of 6.17 specify how the application ought to use this field
> (however, according to the RFC2119 definition of "should" there may be valid
> reasons why the application could use the field in a different way).
> However, there is no indication that the field can be omitted.
> 
> If my interpretation is correct then:
> 
> 1) This seems to be a significant change from the original RFC where
> inclusion of the field was indicated as optional in table 4. How would this
> affect backwards compatibility?
> 
> 2) Perhaps it would be useful to add the sentence "It must be included in
> every request" after the first sentence of 6.17.
> 
> 3) There appears to be an inconsistency between the mandatory requirement to
> include the field and the sentence of 6.17 referring to the case when it is
> absent in a received request. If a mandatory field is absent, oughtn't it to
> be treated as a protocol error?
> 
> I'm ready to be corrected in my interpretation!
> 
> --
> Alex Hardisty
> PQM Consultants
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 28 02:47:04 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22182
	for ; Fri, 28 Jul 2000 02:47:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 35D82443C4; Fri, 28 Jul 2000 02:46:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 7142044337
	for ; Fri, 28 Jul 2000 02:46:13 -0400 (EDT)
Received: from dynamicsoft.com (1Cust16.tnt3.freehold.nj.da.uu.net [63.25.172.16])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA01385;
	Fri, 28 Jul 2000 02:31:14 -0400 (EDT)
Message-ID: <3981295A.85ED45B9@dynamicsoft.com>
Date: Fri, 28 Jul 2000 02:34:02 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rafi 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] ACK received after crash
References: <068f01bff85a$d5ad1b20$8c40000a@sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Session timer.

-Jonathan R.

> rafi wrote:
> 
> 
> Consider the following call scenario,
> 
> 
> A                                  B
> 
> 
>                INVITE
> 
>    ----------------------------------->
> 
>                200 OK
>   <-----------------------------------
> 
>                          Server Crashes here
> 
>                            Server Comes Up
> 
>             ACK
>   -------------------------------->
> 
>                      Finds call id is invalid
>                      and discards the ACK silently
> 
> 
> 
>  Thus in the above call scenario, A is under the impression
> that call is through but actually call is not established end to end.
> One could argue that when user at A actually start using media
> he may not hear  anything from other end and MAY release the
> call. Thus in general  how A  detect this and release the call as
> soon as possible ?
> 
> Thank You
> Rafi Assadi H.M.

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 28 03:05:56 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28347
	for ; Fri, 28 Jul 2000 03:05:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9CBEE4439F; Fri, 28 Jul 2000 03:05:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 70CC744337
	for ; Fri, 28 Jul 2000 03:05:12 -0400 (EDT)
Received: from dynamicsoft.com (1Cust16.tnt3.freehold.nj.da.uu.net [63.25.172.16])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA01440;
	Fri, 28 Jul 2000 03:05:49 -0400 (EDT)
Message-ID: <39813176.7B81263F@dynamicsoft.com>
Date: Fri, 28 Jul 2000 03:08:38 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jo Hornsby 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Clarification on 12.4 and non-INVITEs.
References: <000b01bff647$40971fa0$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jo Hornsby wrote:
> 
> Hi,
> 
> May I humbly &:) suggest new wording for the paragraph on dealing
> with 2xx responses in section 12.4:
> 
> From:
> "The proxy MUST forward the response upstream towards the client,
>  without sending an ACK down-stream."
> 
> To:
> "If the request is an INVITE, the proxy MUST forward the response
>  upstream, without sending an ACK downstream.  If the request is
>  non-INVITE, the proxy should only forward the response upstream
>  if it has not already forwarded a different (or similar) response."

different or similar? Not clear what that means. I think you mean
"should
only forward the response upstream if it has not forwarded any response
upstream".

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 28 03:12: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 ESMTP id DAA00600
	for ; Fri, 28 Jul 2000 03:12:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3F066443BC; Fri, 28 Jul 2000 03:12:51 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1B7DD44337
	for ; Fri, 28 Jul 2000 03:12:49 -0400 (EDT)
Received: from dynamicsoft.com (1Cust16.tnt3.freehold.nj.da.uu.net [63.25.172.16])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA01452;
	Fri, 28 Jul 2000 03:14:02 -0400 (EDT)
Message-ID: <39813362.42731364@dynamicsoft.com>
Date: Fri, 28 Jul 2000 03:16:50 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Simon Barber 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP and T.38?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Simon Barber wrote:
> 
> for an RTP connection the receiver of data opens a specific UDP port number
> on which to receive RTP packets. The RTP connection is defined by the
> specific port number and IP address tuple of the receiver (please correct me
> if I'm wrong - this is from memory). The sender then sends data (from any IP
> address or port) to this receiver. Multiple talkers in a conference are
> distinguished by different SSRCs. These can be received BOTH in multicast
> mode AND in unicast mode. (does anyone have any idea if any SIP UAs support
> multiple SSRCs at the moment?)
> 
> For a TCP connection the connection is opened in a specific direction, but
> is then 2 way (data exchange can happen in either, or both directions).

It need not be the case. As Henning has pointed out, with what I was
proposing you would end up with two tcp connections, each one only being
used for data in one direction.

> The
> connection is defined by the 4 tuple of sender address and port, and
> receiver address and port. A second backwards connection cannot be opened
> with the same address/port numbers as the original connection.

It wouldn't be opened in the reverse direction with the same 5-tuple. If
A calls B, A provides B with a receive IP address and receive port, A.IP
and A.port. In the 200 OK, B provides A with a IP address and port, B.IP
and B.port. A opens a TCP connection to B on B's IP and port, resulting
in the tuple (source address, source port, destination address,
destination port) on A:

(A.IP, A.availableport, B.IP, B.port, TCP)

and then B opens to A, resulting in the tuple on A:

(A.IP, A.port, B.IP, B.availableport, TCP)

these are not the same.



Actually, the ideal case is to do this symmetric open, and then allow
both sides to actually use either TCP connection to send. This has the
advantage that if one (and only one) party is behind a firewall, and IFF
the firewall allows outbound TCP connections, one of these two will
succeed, and then that connection can be used by both parties.

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 28 05:00:00 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06568
	for ; Fri, 28 Jul 2000 05:00:00 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 899AF4436D; Fri, 28 Jul 2000 04:59:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 4129844337
	for ; Fri, 28 Jul 2000 04:59:12 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA10421; Fri, 28 Jul 2000 09:57:14 +0100 (BST)
From: "Jo Hornsby" 
To: "Jonathan Rosenberg" 
Cc: "Henning Schulzrinne" ,
        
Subject: RE: [SIP] ACK handling at Stateful Proxies
Date: Fri, 28 Jul 2000 09:57:14 +0100
Message-ID: <002d01bff871$d2efff80$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <39804DDD.3C6072D5@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> > Consider that two UAs are in an (audio) call.  The caller decides
> > that they would like to add video.  The callee's UA interactively
> > asks the callee if it's okay to add the video stream.  The callee
> > is temporarily distracted, and does not initially see the prompt.
> > An intermediate proxy times out, returns a 408 and sends a CANCEL
> > downstream.  Meanwhile the callee has accepted the video and the
> > callee's UA returns 200 before it sees the CANCEL.  The timed-out
> > (and any other) proxies have to forward the 200, so the caller's
> > UA sees both a 408 and a 200 (note that it is not necessarily
> > obvious which order these will arrive in).
> 
> I'll note that this won't happen in the proxy uses the new CANCEL rules
> (the 487 stuff). In that case, it won't send a response after CANCEL, it
> will wait to receive the 487 and then forward that.

Hmmm... have I misunderstood 487?

Consider the following scenario:
  UA1 sends an INVITE to UA2, and that INVITE traverses proxies P1
  and P2.  At some point later, P1 times-out on the INVITE and sends
  a CANCEL to P2; P2 in turn sends a CANCEL to UA2, but UA2 sends
  a 200 at the same time.


    UA1            P1            P2            UA2
        -- INV -->
        <-- 100 --
                      -- INV -->
                      <-- 100 --
                                    -- INV -->
                                    <-- 100 --
[0]
                      -- CCL -->
        <-- 408 --
                                    <-- 200 --
[1]
                                    -- CCL -->
[2]
                      <-- 487 --
                      <-- 200 --
        <-- 200 --
              
[0] some time passes, and P1 times-out
[1] 200 (above) and (CANCEL) below "cross on the wire"
[2] note that UA2 does not return 487, because it has already
    returned a final response

Result: UA1 sees a 408 followed by a 200, but will probably
        only see the 200 as a retransmission of the 408.
        Subsequent ACKs will be ambiguous.

> The other case which can cause multiple responses is forking, but
> reinvites will, with the bis draft, never be forked. Thats because
> the UAS inserts a Contact into the 200 OK. Reinvites thus always
> have a route directly to the UAS.

Agreed...

> So, in practice, this problem will go away once everyone has
> implemented the bis draft.

...but not so sure about this (unless scenario above is not
bis-Correct[tm]).

> In the interim, it can happen. In this case, I would recommend
> forwarding ACKs that match a 200 OK you've sent upstream.

Even though the UA might not have seen the 200, and is even
less likely to as a result of forwarding the ACK?  Also, should
this ACK halt the 487 (or whatever) retransmissions?


 - 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 Jul 28 05:38:08 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18829
	for ; Fri, 28 Jul 2000 05:38:08 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 064EB4437A; Fri, 28 Jul 2000 05:37:56 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 6950B44337
	for ; Fri, 28 Jul 2000 05:37:49 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA13099; Fri, 28 Jul 2000 10:35:33 +0100 (BST)
From: "Jo Hornsby" 
To: "Hong Chen" , 
Subject: RE: [SIP] Call Park abd Call Pickup
Date: Fri, 28 Jul 2000 10:35:33 +0100
Message-ID: <002f01bff877$2d3e5680$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <39807F7B.868F8E02@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> I need helps to understand how to implement CALL Park and Call Pickup
> features by SIP?

As far as "Call Pickup", I would look up the thread
"on directed pick up service" in the archives; it caused a
small staircase at the beginning of this month.

I'll have a bash at "Call Park".  If I remember it rightly (I'm
harking back to my days working in a supermarket, and
retrospectively injecting my small amount of telephony switch
knowledge, so please forgive me), it's when a call is
(temporarily) terminated at some logical point in the switch,
right?  And this call can then be picked-up from an arbitrary
'phone by dialling a feature code, or whatever?

Modelling similarly, I guess it could be achieved using a
combination of directed pickup and REFER (transfer); call
is parked by magic of REFER, and is left ringing on some logical
UA somewhere; call is subsequently retrieved by issuing a
REGISTER for that logical UA from the pickup point.

Note that I'm sure there are far more elegant and sophisticated
ways of doing these things within SIP...especially once one has a
rich interface.  I would think that these sort of mappings
only really need to be applied in dumb 'phone environments.

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 Jul 28 05:40:14 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19506
	for ; Fri, 28 Jul 2000 05:40:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B95A2443C2; Fri, 28 Jul 2000 05:39:27 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id D51AF443BC
	for ; Fri, 28 Jul 2000 05:39:19 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA13642; Fri, 28 Jul 2000 10:37:07 +0100 (BST)
From: "Jo Hornsby" 
To: "Jonathan Rosenberg" 
Cc: 
Subject: RE: [SIP] Clarification on 12.4 and non-INVITEs.
Date: Fri, 28 Jul 2000 10:37:07 +0100
Message-ID: <003001bff877$654f8490$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <39813176.7B81263F@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> > From:
> > "The proxy MUST forward the response upstream towards the client,
> >  without sending an ACK down-stream."
> > 
> > To:
> > "If the request is an INVITE, the proxy MUST forward the response
> >  upstream, without sending an ACK downstream.  If the request is
> >  non-INVITE, the proxy should only forward the response upstream
> >  if it has not already forwarded a different (or similar) response."
> 
> different or similar? Not clear what that means. I think you mean
> "should
> only forward the response upstream if it has not forwarded any response
> upstream".

Ah yes.  That's much clearer. &:)


 - 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 Jul 28 07:59:27 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27300
	for ; Fri, 28 Jul 2000 07:59:27 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B8F67443A2; Fri, 28 Jul 2000 07:58:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from nautilus.shore.net (nautilus.shore.net [207.244.124.104])
	by lists.bell-labs.com (Postfix) with ESMTP id 1F7A644337
	for ; Fri, 28 Jul 2000 07:58:35 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by nautilus.shore.net with esmtp (Exim)
	id 13I8mW-0001LY-00; Fri, 28 Jul 2000 07:58:24 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id HAA22070;
	Fri, 28 Jul 2000 07:51:47 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000728075525.00d11ef0@webhost.tactical-sw.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 28 Jul 2000 07:59:10 -0400
To: Jonathan Rosenberg ,
        Simon Barber 
From: David Yon 
Subject: Re: [SIP] SIP and T.38?
Cc: sip@lists.bell-labs.com
In-Reply-To: <39813362.42731364@dynamicsoft.com>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

At 03:16 AM 7/28/00 -0400, Jonathan Rosenberg wrote:



>Actually, the ideal case is to do this symmetric open, and then allow
>both sides to actually use either TCP connection to send. This has the
>advantage that if one (and only one) party is behind a firewall, and IFF
>the firewall allows outbound TCP connections, one of these two will
>succeed, and then that connection can be used by both parties.

         A serious flaw with this is that it forces an unnatural usage of 
TCP into topologies that may not support what you are describing, as I 
discussed in the informal draft I discussed earlier.  TCP works very well 
when used as intended, why contort it into something else when all that's 
needed is a bit of additional SDP information?


David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net



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


From sip-admin@lists.bell-labs.com  Fri Jul 28 09:36:57 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19058
	for ; Fri, 28 Jul 2000 09:36:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 90AF0443AA; Fri, 28 Jul 2000 09:36:26 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.azisa.co.za (mail.azisa.co.za [196.14.124.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 8E14C44339
	for ; Fri, 28 Jul 2000 09:36:20 -0400 (EDT)
Received: by MAIL with Internet Mail Service (5.5.2650.21)
	id ; Fri, 28 Jul 2000 15:37:38 +0200
Message-ID: <934C10A9A64AD4119440009027E0998801C4CD@MAIL>
From: Jacobus Alberts 
To: "Sip List (E-mail)" 
Date: Fri, 28 Jul 2000 15:37:37 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Bye!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi all! Bye ALL!

It has been great working with you all.  Best of luck for SIP!

A+

Jacobus C Alberts

Azisa (Pty) Ltd
email: jalberts@azisa.co.za
Work phone   : +27 11 293 0608
Cellular phone: +27 82 902 0213



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


From sip-admin@lists.bell-labs.com  Fri Jul 28 10:01:47 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24594
	for ; Fri, 28 Jul 2000 10:01:46 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 97482443B8; Fri, 28 Jul 2000 10:01:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 046BE44337
	for ; Fri, 28 Jul 2000 10:01:33 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA02404;
	Fri, 28 Jul 2000 10:02:23 -0400 (EDT)
Message-ID: <3981931A.E71AEE5C@dynamicsoft.com>
Date: Fri, 28 Jul 2000 10:05:14 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jo Hornsby 
Cc: Henning Schulzrinne , sip@lists.bell-labs.com
Subject: Re: [SIP] ACK handling at Stateful Proxies
References: <002d01bff871$d2efff80$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jo Hornsby wrote:
> 
> > > Consider that two UAs are in an (audio) call.  The caller decides
> > > that they would like to add video.  The callee's UA interactively
> > > asks the callee if it's okay to add the video stream.  The callee
> > > is temporarily distracted, and does not initially see the prompt.
> > > An intermediate proxy times out, returns a 408 and sends a CANCEL
> > > downstream.  Meanwhile the callee has accepted the video and the
> > > callee's UA returns 200 before it sees the CANCEL.  The timed-out
> > > (and any other) proxies have to forward the 200, so the caller's
> > > UA sees both a 408 and a 200 (note that it is not necessarily
> > > obvious which order these will arrive in).
> >
> > I'll note that this won't happen in the proxy uses the new CANCEL rules
> > (the 487 stuff). In that case, it won't send a response after CANCEL, it
> > will wait to receive the 487 and then forward that.
> 
> Hmmm... have I misunderstood 487?
> 
> Consider the following scenario:
>   UA1 sends an INVITE to UA2, and that INVITE traverses proxies P1
>   and P2.  At some point later, P1 times-out on the INVITE and sends
>   a CANCEL to P2; P2 in turn sends a CANCEL to UA2, but UA2 sends
>   a 200 at the same time.
> 
>     UA1            P1            P2            UA2
>         -- INV -->
>         <-- 100 --
>                       -- INV -->
>                       <-- 100 --
>                                     -- INV -->
>                                     <-- 100 --
> [0]
>                       -- CCL -->
>         <-- 408 --
>                                     <-- 200 --
> [1]
>                                     -- CCL -->
> [2]
>                       <-- 487 --
>                       <-- 200 --
>         <-- 200 --
> 
> [0] some time passes, and P1 times-out
> [1] 200 (above) and (CANCEL) below "cross on the wire"
> [2] note that UA2 does not return 487, because it has already
>     returned a final response

Thats the problem. What I'm arguing is that upon sending cancel, P1
should NOT at that point return a 408, but rather wait for the
487. If everyone implemented bis, it would get this 487 right away
(modulo packet losses), or get a different final response if that
response and the CANCEL pass on the wire.

> > In the interim, it can happen. In this case, I would recommend
> > forwarding ACKs that match a 200 OK you've sent upstream.
> 
> Even though the UA might not have seen the 200, and is even
> less likely to as a result of forwarding the ACK?  Also, should
> this ACK halt the 487 (or whatever) retransmissions?

Hmm. Actually, there is a way to distinguish these two ACKs. If the UAS
is
acking the non-200, the ACK won't contain any Route headers. If the ACK
is for the 200, it will. So, if the proxy receives an ACK without route
headers, it knows the ACK is for it. Works so long as UAS inserts
Contact.

Sound right?

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 28 10:36:18 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02902
	for ; Fri, 28 Jul 2000 10:36:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 706AF443AD; Fri, 28 Jul 2000 10:35:25 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 03C6044337
	for ; Fri, 28 Jul 2000 10:35:21 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA28082; Fri, 28 Jul 2000 15:33:15 +0100 (BST)
From: "Jo Hornsby" 
To: "Jonathan Rosenberg" 
Cc: "Henning Schulzrinne" ,
        
Subject: RE: [SIP] ACK handling at Stateful Proxies
Date: Fri, 28 Jul 2000 15:33:15 +0100
Message-ID: <003901bff8a0$c42729e0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <3981931A.E71AEE5C@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

> Thats the problem. What I'm arguing is that upon sending cancel, P1
> should NOT at that point return a 408, but rather wait for the
> 487. If everyone implemented bis, it would get this 487 right away
> (modulo packet losses), or get a different final response if that
> response and the CANCEL pass on the wire.

Ah right, I see.  I guess we'll have to kick of another timer,
in case the next downstream stateful-proxy/UA doesn't return a
487.  But that's no biggie.

> > > In the interim, it can happen. In this case, I would recommend
> > > forwarding ACKs that match a 200 OK you've sent upstream.
> > 
> > Even though the UA might not have seen the 200, and is even
> > less likely to as a result of forwarding the ACK?  Also, should
> > this ACK halt the 487 (or whatever) retransmissions?
> 
> Hmm. Actually, there is a way to distinguish these two ACKs. If the UAS
> is
> acking the non-200, the ACK won't contain any Route headers. If the ACK
> is for the 200, it will. So, if the proxy receives an ACK without route
> headers, it knows the ACK is for it. Works so long as UAS inserts
> Contact.

Very sweet.

> Sound right?

Yup -- works for me.

Cheers,


 - Jo.



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


From sip-admin@lists.bell-labs.com  Fri Jul 28 10:50:22 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06091
	for ; Fri, 28 Jul 2000 10:50:21 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A0681443C9; Fri, 28 Jul 2000 10:48:57 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from abel.senecanetworks.com (unknown [63.97.216.18])
	by lists.bell-labs.com (Postfix) with ESMTP id 5B3424433A
	for ; Fri, 28 Jul 2000 10:48:54 -0400 (EDT)
Received: from vsharmapc (dhcp67.senecanetworks.com [10.0.1.67] (may be forged))
	by abel.senecanetworks.com (8.9.3/8.8.7) with SMTP id FAA09460
	for ; Fri, 28 Jul 2000 05:46:50 -0500
From: "Vipul Sharma" 
To: 
Date: Fri, 28 Jul 2000 10:48:49 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <003901bff8a0$c42729e0$4e34c3c1@ubiquity.co.uk>
Subject: [SIP] RE: RFC's ..Where are they (smile) ???
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi!,
	This is not exactly a SIP question/issue (my apologies).....But could
someone point me to where I can find the RFC's that are going to be
discussed in Pittsburgh. I am told that they are available in zipped (or
some other) format. Thanks in advance for your help.

Vip




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


From sip-admin@lists.bell-labs.com  Fri Jul 28 11:08:10 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10700
	for ; Fri, 28 Jul 2000 11:08:08 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E6620443B6; Fri, 28 Jul 2000 11:07:47 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 19955443B5
	for ; Fri, 28 Jul 2000 11:07:45 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0FYE00701Y0MJF@firewall.mcit.com> for sip@lists.bell-labs.com; Fri,
 28 Jul 2000 15:07:34 +0000 (GMT)
Received: from dgismtp03.wcomnet.com ([166.38.58.143])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FYE00LKJY0MME@firewall.mcit.com>; Fri,
 28 Jul 2000 15:07:34 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262)
 id <0FYE00001XYI2H@dgismtp03.wcomnet.com>; Fri,
 28 Jul 2000 15:06:18 +0000 (GMT)
Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0FYE00N01XXP2T@dgismtp03.wcomnet.com>;
 Fri, 28 Jul 2000 15:06:18 +0000 (GMT)
Received: from C25776A ([166.35.227.169])
 by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0FYE00JJRXXNJK@dgismtp03.wcomnet.com>; Fri,
 28 Jul 2000 15:05:48 +0000 (GMT)
Date: Fri, 28 Jul 2000 10:07:03 -0500
From: Henry Sinnreich 
Subject: RE: [SIP] RE: RFC's ..Where are they (smile) ???
In-reply-to: 
To: Vipul Sharma , sip@lists.bell-labs.com
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

See the IETF web site and search at
http://search.ietf.org/search/brokers/internet-drafts/query.html

The SIP WG is at
http://search.ietf.org/html.charters/sip-charter.html

and there is an additional web page for all SIP related drafts
at
http://www.softarmor.com/sipwg/drafts/

Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Vipul Sharma
>Sent: Friday, July 28, 2000 9:49 AM
>To: sip@lists.bell-labs.com
>Subject: [SIP] RE: RFC's ..Where are they (smile) ???
>
>
>Hi!,
>	This is not exactly a SIP question/issue (my
>apologies).....But could
>someone point me to where I can find the RFC's that
>are going to be
>discussed in Pittsburgh. I am told that they are
>available in zipped (or
>some other) format. Thanks in advance for your help.
>
>Vip
>
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/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 Jul 28 11:29:35 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17668
	for ; Fri, 28 Jul 2000 11:29:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5CC0E443B5; Fri, 28 Jul 2000 11:29:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C6B0044336
	for ; Fri, 28 Jul 2000 11:29:03 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA03424;
	Fri, 28 Jul 2000 11:30:32 -0400 (EDT)
Message-ID: <3981A7C3.4B2E3E09@dynamicsoft.com>
Date: Fri, 28 Jul 2000 11:33:23 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henry Sinnreich 
Cc: Vipul Sharma , sip@lists.bell-labs.com
Subject: Re: [SIP] RE: RFC's ..Where are they (smile) ???
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

The list of drafts for this meeting is also at:

http://www.softarmor.com/sipwg/meets/IETF48/agenda.htm

-Jonathan R.

Henry Sinnreich wrote:
> 
> See the IETF web site and search at
> http://search.ietf.org/search/brokers/internet-drafts/query.html
> 
> The SIP WG is at
> http://search.ietf.org/html.charters/sip-charter.html
> 
> and there is an additional web page for all SIP related drafts
> at
> http://www.softarmor.com/sipwg/drafts/
> 
> Henry
> 
> >-----Original Message-----
> >From: sip-admin@lists.bell-labs.com
> >[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Vipul Sharma
> >Sent: Friday, July 28, 2000 9:49 AM
> >To: sip@lists.bell-labs.com
> >Subject: [SIP] RE: RFC's ..Where are they (smile) ???
> >
> >
> >Hi!,
> >       This is not exactly a SIP question/issue (my
> >apologies).....But could
> >someone point me to where I can find the RFC's that
> >are going to be
> >discussed in Pittsburgh. I am told that they are
> >available in zipped (or
> >some other) format. Thanks in advance for your help.
> >
> >Vip
> >
> >
> >
> >
> >_______________________________________________
> >SIP mailing list
> >SIP@lists.bell-labs.com
> >http://lists.bell-labs.com/mailman/listinfo/sip
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

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


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


From sip-admin@lists.bell-labs.com  Fri Jul 28 12:22:27 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02384
	for ; Fri, 28 Jul 2000 12:22:26 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CD9D94439E; Fri, 28 Jul 2000 12:22:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 442A544336
	for ; Fri, 28 Jul 2000 12:22:06 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6SGM5Q22674
	for ; Fri, 28 Jul 2000 18:22:05 +0200 (MEST)
Received: from SMTP ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1);
	 Fri, 28 Jul 2000 18:22:05 +0200
Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by 153.88.251.29
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 28 Jul 2000 16:22:05 0000 (GMT)
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id ; Fri, 28 Jul 2000 18:20:51 +0200
Message-ID: <56E7307B0850D411B1480008C75DD5EAB73BF8@enlrynt303.dsn.ericsson.se>
From: "Arnoud van Wijk (ETM)" 
To: "'sip@lists.bell-labs.com'" 
Date: Fri, 28 Jul 2000 18:20:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-OriginalArrivalTime: 28 Jul 2000 16:22:05.0470 (UTC) FILETIME=[F8142BE0:01BFF8AF]
Subject: [SIP] (no subject)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Great!

I am hearing impaired and it makes me happy that the trio Rosenberg, Schulzrinne and Sinnreich are writing the draft: draft-rosenberg-sip-hearingimpaired-00.txt
:-)

So..I am volunteering as test subject for related experiments.
(and I am NOT speech impaired. Just lipreading for me).

Greetz

Arnoud

_______________________________________________________________
ERICSSON TELECOMMUNICATIE BV
Arnoud van Wijk
Research & Development
ETM/BL/RE
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  Fri Jul 28 13:44:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22938
	for ; Fri, 28 Jul 2000 13:44:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 897E9443C8; Fri, 28 Jul 2000 13:39:47 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5DBD944336; Fri, 28 Jul 2000 13:39:40 -0400 (EDT)
Received: by dnspri.npac.com; id MAA23960; Fri, 28 Jul 2000 12:39:39 -0500 (CDT)
Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0)
	id xma023767; Fri, 28 Jul 00 12:38:44 -0500
Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0)
	id ; Fri, 28 Jul 2000 12:37:57 -0500
Message-ID: 
From: James Yu 
To: "'sip@lists.bell-labs.com'" ,
        "'iptel@lists.bell-labs.com'" ,
        "'sip-h323@egroups.com'" 
Date: Fri, 28 Jul 2000 12:36:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] draft-yu-tel-url-00.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Please note that I've submitted the following I-D:

draft-yu-tel-url-00.txt, "Extensions to the 'tel' and 'fax' URLs to Support
Number Portability", James Yu, 07/11/2000. (14995 bytes). 
     Number portability (NP) allows the telephone subscribers to keep their
telephone numbers when they change service provider, move to a
     new location, or change the subscribed services. The NP implementations
in many countries presently support service provider portability
     for geographic numbers and non-geographical numbers. It has been
identified that NP has impacts on several works-in-progress at the
     IETF. One of the impacts is to carry the NP related information in the
SIP INVITE message. This document proposed the extensions to
     the 'tel' and 'fax' Uniform Resource Locators (URLs) to support NP so
that they can be used to carry the NP related information in the
     Session Initiation Protocol (SIP) Request-URI.

The proposed new parameter is considered as the "future-extension"  for the
global-phone-number and local-phone-number.  The next draft will allow the
"visual-separator"  in the "rn-ident" that is shown in the example of the
current draft and add a reference to ABNF.  It is also possible to separate
the "routing-number" and "npdb-dip-indicator" as two new parameters (In some
cases, they are both present for number portability. In other cases,
routing-number can be present for routing purpose independent of number
portability.   Since SIP can carry the "tel" URL, there may be a need to
address SIP-H.323 interworking if this proposal is adopted. 

Your comments are appreciated.

James Yu
Principal Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue, NW,
Suite 550
Washington, D.C. 20005
USA
+1-202-533-2814 (B)
+1-202-533-2976 (Fax)
+1-202-256-1200 (Mobile)
james.yu@neustar.com
http://www.neustar.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 Jul 28 13:49:43 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24081
	for ; Fri, 28 Jul 2000 13:49:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D9F9E443E7; Fri, 28 Jul 2000 13:44:41 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 1F098443DD
	for ; Fri, 28 Jul 2000 13:44:37 -0400 (EDT)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA19749;
	Fri, 28 Jul 2000 10:44:52 -0700 (PDT)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAB85323;
	Fri, 28 Jul 2000 10:44:34 -0700 (PDT)
Message-Id: <4.2.0.58.20000728102756.01bdb580@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 28 Jul 2000 10:43:48 -0700
To: "Jo Hornsby" 
From: Rohan Mahy 
Subject: RE: [SIP] Call Park abd Call Pickup
Cc: "Hong Chen" , 
In-Reply-To: <002f01bff877$2d3e5680$4e34c3c1@ubiquity.co.uk>
References: <39807F7B.868F8E02@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi,

I think Pickup was well described in a previous thread.  If you wanted to 
do traditional Park things, I can think of 4 variations (with or without 
music, and with or without Revert)

I think I am suggesting essentially the same thing as Jo did.  You can read 
both and see if either make sense to you.

A and B have an existing session.

B sends a REFER to A, which redirects their session to

         

the forwarding logic for "so-queue-me"  would return a 182 call queued.  If 
desired, music/announcements could be played using 183 with Session: media.
To retrieve the call just REGISTER "park-12" with a short expires timer.

If revert was desired, the forwarding logic would eventually give up and 
forward the INVITE to the parker or an attendant.

hope this helps.  thanks,
-rohan


At 02:35 AM 7/28/00 , Jo Hornsby wrote:
> > I need helps to understand how to implement CALL Park and Call Pickup
> > features by SIP?
>
>As far as "Call Pickup", I would look up the thread
>"on directed pick up service" in the archives; it caused a
>small staircase at the beginning of this month.
>
>I'll have a bash at "Call Park".  If I remember it rightly (I'm
>harking back to my days working in a supermarket, and
>retrospectively injecting my small amount of telephony switch
>knowledge, so please forgive me), it's when a call is
>(temporarily) terminated at some logical point in the switch,
>right?  And this call can then be picked-up from an arbitrary
>'phone by dialling a feature code, or whatever?
>
>Modelling similarly, I guess it could be achieved using a
>combination of directed pickup and REFER (transfer); call
>is parked by magic of REFER, and is left ringing on some logical
>UA somewhere; call is subsequently retrieved by issuing a
>REGISTER for that logical UA from the pickup point.
>
>Note that I'm sure there are far more elegant and sophisticated
>ways of doing these things within SIP...especially once one has a
>rich interface.  I would think that these sort of mappings
>only really need to be applied in dumb 'phone environments.
>
>Cheers,
>
>
>  - Jo.
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip



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


From sip-admin@lists.bell-labs.com  Fri Jul 28 16:24:46 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07592
	for ; Fri, 28 Jul 2000 16:24:45 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 68A64443D1; Fri, 28 Jul 2000 16:24:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 864F944363
	for ; Fri, 28 Jul 2000 16:24:09 -0400 (EDT)
Received: from dynamicsoft.com (DYN001-DA02A03-82.arcommunications.net [64.17.132.211])
	by kevlar.softarmor.com (8.9.3/8.9.3) with ESMTP id CAA30719
	for ; Sat, 29 Jul 2000 02:27:18 -0500
Message-ID: <3981EC45.875541A1@dynamicsoft.com>
Date: Fri, 28 Jul 2000 15:25:42 -0500
From: Dean Willis 
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] SIP WG Presentations for IETF 48
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


I have started to accumulate slides at:

http://www.softarmor.com/sipwg/meets/IETF48/slides/

It developed at IETF 47 that the people who publish the proceedings will
only accept HTML or HTMLable PPT slides in the proceedings. They
apparently did not include the PDF slides into the published
proceedings. Actually, I'm just assuming they will accept HTML, given
that they turned all the PPT files into HTML. We didn't actually have
any native HTML slides in the experiment.

Therefore I suggest that you submit materials in either PPT or HTML
format or go beat the people in POISSON about why it is necessary to
publish in a Microsoft proprietary format for publication in the IETF.

Please submit slides to me for inclusion on our web site as they become
available.

Note also that a draft agenda and draft reading list is posted at:

http://www.softarmor.com/sipwg/meets/IETF48/agenda.htm

Thanks,

--
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  Fri Jul 28 16:38:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10642
	for ; Fri, 28 Jul 2000 16:38:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A7CBA443D6; Fri, 28 Jul 2000 16:37:58 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 6AAB544336
	for ; Fri, 28 Jul 2000 16:37:54 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0FYF00C01DAWWJ@firewall.mcit.com> for sip@lists.bell-labs.com; Fri,
 28 Jul 2000 20:37:44 +0000 (GMT)
Received: from dgismtp04.wcomnet.com ([166.38.58.144])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FYF000LDDAWZ4@firewall.mcit.com>; Fri,
 28 Jul 2000 20:37:44 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 id <0FYF00601DB3Q1@dgismtp04.wcomnet.com>; Fri,
 28 Jul 2000 20:38:29 +0000 (GMT)
Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0FYF00601D97I6@dgismtp04.wcomnet.com>;
 Fri, 28 Jul 2000 20:36:49 +0000 (GMT)
Received: from C25776A ([166.46.18.141])
 by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0FYF00611D8264@dgismtp04.wcomnet.com>; Fri,
 28 Jul 2000 20:36:31 +0000 (GMT)
Date: Fri, 28 Jul 2000 15:35:44 -0500
From: Henry Sinnreich 
Subject: RE: [SIP] (no subject)
In-reply-to: <56E7307B0850D411B1480008C75DD5EAB73BF8@enlrynt303.dsn.ericsson.se>
To: "Arnoud van Wijk (ETM)" ,
        sip@lists.bell-labs.com
Cc: EUSCSGE@am1.ericsson.se
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

>So..I am volunteering as test subject for related experiments.

Actually, now that we have started this project, the next
logical step is to have a proper requirements draft.
Hearing disabled engineers on this list would be the best
qualified to contribute.
Cathy Gearhart has kindly offered to contribute, Cathy is an
interpreter for relay service.
Would you like to contribute to a requirements draft?
Anyone else on the list who may be interested in a requirements
draft on SIP for the hearing disabled?

Thanks, Henry

>-----Original Message-----
>From: sip-admin@lists.bell-labs.com
>[mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>Arnoud van Wijk (ETM)
>Sent: Friday, July 28, 2000 11:21 AM
>To: 'sip@lists.bell-labs.com'
>Subject: [SIP] (no subject)
>
>
>Great!
>
>I am hearing impaired and it makes me happy that the
>trio Rosenberg, Schulzrinne and Sinnreich are writing
>the draft: draft-rosenberg-sip-hearingimpaired-00.txt
>:-)
>
>So..I am volunteering as test subject for related experiments.
>(and I am NOT speech impaired. Just lipreading for me).
>
>Greetz
>
>Arnoud
>
>_______________________________________________________________
>ERICSSON TELECOMMUNICATIE BV
>Arnoud van Wijk
>Research & Development
>ETM/BL/RE
>Fax: +31-161 247569
>______________________________________________________________
>
>
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/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 Jul 28 17:22:44 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21566
	for ; Fri, 28 Jul 2000 17:22:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EFAAB44366; Fri, 28 Jul 2000 17:22:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 72FEF44336
	for ; Fri, 28 Jul 2000 17:22:05 -0400 (EDT)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256)
 id <0FYF00601FCPW8@firewall.mcit.com> for sip@lists.bell-labs.com; Fri,
 28 Jul 2000 21:22:01 +0000 (GMT)
Received: from dgismtp03.wcomnet.com ([166.38.58.143])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FYF00M8DFCPLR@firewall.mcit.com>; Fri,
 28 Jul 2000 21:22:01 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262)
 id <0FYF00901FALM1@dgismtp03.wcomnet.com>; Fri,
 28 Jul 2000 21:20:45 +0000 (GMT)
Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0FYF00901FADLI@dgismtp03.wcomnet.com>;
 Fri, 28 Jul 2000 21:20:45 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.214.9])
 by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FYF004GUFAAMF@dgismtp03.wcomnet.com>; Fri,
 28 Jul 2000 21:20:34 +0000 (GMT)
Received: from wcom.com ([166.33.132.102])
 by omzmta03.mcit.com (InterMail v03.02.07 118-124-101)
 with ESMTP id <20000728212149.RNOV671@wcom.com>; Fri,
 28 Jul 2000 21:21:49 +0000
Date: Fri, 28 Jul 2000 16:22:51 -0500
From: Alan Johnston 
Subject: Re: [SIP] Re: summary: DTMF and voice-over-packet
To: Jonathan Rosenberg 
Cc: Serban Tatu , sip@lists.bell-labs.com
Message-id: <3981F9AB.297E7071@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: <081101bff32a$f731df40$abd0a8c0@starvision.com>
 <39787580.6C0EED25@dynamicsoft.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:

> Serban Tatu wrote:
> >
> > 2. Some people say that RTP/RFC2833 is the way to go. However, in the SIP Call
> > Flows Examples draft
> > (http://search.ietf.org/internet-drafts/draft-ietf-sip-call-flows-01.txt),
> > section 5.1. shows a DTMF digit carried by an INFO request. What's that thing
> > doing there?
>
> Oops. That needs to go. The call flows draft should only be referencing
> standard approaches for message flows.
>
> >

I'll remove that example and add in a different example of an INFO request.
Suggestions for call flows are always greatly appreciated.

Alan Johnston
WorldCom.



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


From sip-admin@lists.bell-labs.com  Sat Jul 29 14:20:24 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29309
	for ; Sat, 29 Jul 2000 14:20:24 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AA1BE4435D; Sat, 29 Jul 2000 14:19:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from altavistausa.com (max1-3.newyork.corecomm.net [209.81.238.131])
	by lists.bell-labs.com (Postfix) with SMTP
	id 9FB5844336; Sat, 29 Jul 2000 14:19:43 -0400 (EDT)
From: 
Date: Sat, 29 Jul 2000 15:16:06
Message-Id: <457.582204.766577@altavistausa.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Subject: [SIP] From Lorraine,as promised,I can lower your bill
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com





Untitled Document








 

Today, everyone knows the impact of the Internet.

But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!



Uk $.04     France $.06    UAE  $.31
   Saudi Arabia $.59     Denmark $.04
     Sweden $.05



Click Here Now. 



If you do not have flash please go to

www.macromedia.com

to download it.







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


From sip-admin@lists.bell-labs.com  Sat Jul 29 15:48:10 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09769
	for ; Sat, 29 Jul 2000 15:48:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8841B44356; Sat, 29 Jul 2000 15:47:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from charlie.cns.iit.edu (charlie.cns.iit.edu [216.47.143.70])
	by lists.bell-labs.com (Postfix) with ESMTP id DC82644336
	for ; Sat, 29 Jul 2000 15:47:34 -0400 (EDT)
Received: (from pantdee@localhost) by charlie.cns.iit.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA47492 for sip@lists.bell-labs.com; Sat, 29 Jul 2000 14:47:40 -0500 (CDT)
From: pantdee@charlie.cns.iit.edu (Deepak Pant)
Message-Id: <200007291947.OAA47492@charlie.cns.iit.edu>
To: sip@lists.bell-labs.com
Date: Sat, 29 Jul 2000 14:47:34 -0500 (CDT)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Behaviour of the expires header
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Does every proxy that receives an INVITE request
needs to process the expires header? If every proxy
processes an INVITE request with the expires header,
then at the expiry of the INVITE, every proxy will
issue a 408 status.

-Deepak


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


From sip-admin@lists.bell-labs.com  Sat Jul 29 18:40:47 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29195
	for ; Sat, 29 Jul 2000 18:40:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 642BF44354; Sat, 29 Jul 2000 18:40:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157])
	by lists.bell-labs.com (Postfix) with ESMTP id 31F9B44336
	for ; Sat, 29 Jul 2000 18:40:11 -0400 (EDT)
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA29214;
	Sat, 29 Jul 2000 18:38:39 -0400 (EDT)
Message-ID: <39835CF0.DDC72F0A@cs.columbia.edu>
Date: Sat, 29 Jul 2000 18:38:40 -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: Alex Hardisty , brett@broadsoft.com,
        sip@lists.bell-labs.com
Subject: Re: [SIP] rfc2543bis: table 4 comments
References:  <39812A72.3ED81E42@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Created an m* category: SHOULD sent, but receivers need to be prepared
to receive a request without it. Does that work?

Jonathan Rosenberg wrote:
> 
> I actually think SHOULD is 'o' as opposed to 'm'. As Alex points out,
> for backwards compatibility you will need to handle the case of not
> getting a 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  Sat Jul 29 21:55:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23431
	for ; Sat, 29 Jul 2000 21:55:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5CAC54434A; Sat, 29 Jul 2000 21:54:32 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id E97D744336
	for ; Sat, 29 Jul 2000 21:54:28 -0400 (EDT)
Received: from dynamicsoft.com (1Cust154.tnt1.freehold.nj.da.uu.net [63.17.113.154])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA08200;
	Sat, 29 Jul 2000 21:55:46 -0400 (EDT)
Message-ID: <39838BCD.47F18C29@dynamicsoft.com>
Date: Sat, 29 Jul 2000 21:58:37 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
Cc: Alex Hardisty , brett@broadsoft.com,
        sip@lists.bell-labs.com
Subject: Re: [SIP] rfc2543bis: table 4 comments
References:  <39812A72.3ED81E42@dynamicsoft.com> <39835CF0.DDC72F0A@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:
> 
> Created an m* category: SHOULD sent, but receivers need to be prepared
> to receive a request without it. Does that work?

Sure; receivers needing to be prepared to receive a request without it
is a natural consqeuence of SHOULD send.

-Jonathan R.

> 
> Jonathan Rosenberg wrote:
> >
> > I actually think SHOULD is 'o' as opposed to 'm'. As Alex points out,
> > for backwards compatibility you will need to handle the case of not
> > getting a Content-Length.
> >

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


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


From sip-admin@lists.bell-labs.com  Sat Jul 29 22:11:20 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25247
	for ; Sat, 29 Jul 2000 22:11:20 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DE9D7443AC; Sat, 29 Jul 2000 22:10:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156])
	by lists.bell-labs.com (Postfix) with ESMTP id 3080044336
	for ; Sat, 29 Jul 2000 22:10:40 -0400 (EDT)
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id WAA22868;
	Sat, 29 Jul 2000 22:09:54 -0400 (EDT)
Message-ID: <39838E75.5D4DB3FB@cs.columbia.edu>
Date: Sat, 29 Jul 2000 22:09:57 -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: Jo Hornsby 
Cc: Hong Chen , sip@lists.bell-labs.com
Subject: Re: [SIP] Call Park abd Call Pickup
References: <002f01bff877$2d3e5680$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

I think this may be a feature where we should ask "what do we want to
accomplish from a user perspective", not "how do we replicate a feature
called Call Park/Pickup". In particular, is this used for some unknown
party to pick up, after the clerk hollers into the store PA system
"whoever is in the adult diaper aisle, call on line 1?". If you know who
you're addressing, with personal mobility, you can just transfer or
redirect the call, without the intermediate parking.

Jo Hornsby wrote:
> 
> > I need helps to understand how to implement CALL Park and Call Pickup
> > features by SIP?
> 
> As far as "Call Pickup", I would look up the thread
> "on directed pick up service" in the archives; it caused a
> small staircase at the beginning of this month.
> 
> I'll have a bash at "Call Park".  If I remember it rightly (I'm
> harking back to my days working in a supermarket, and
> retrospectively injecting my small amount of telephony switch
> knowledge, so please forgive me), it's when a call is
> (temporarily) terminated at some logical point in the switch,
> right?  And this call can then be picked-up from an arbitrary
> 'phone by dialling a feature code, or whatever?
> 
> Modelling similarly, I guess it could be achieved using a
> combination of directed pickup and REFER (transfer); call
> is parked by magic of REFER, and is left ringing on some logical
> UA somewhere; call is subsequently retrieved by issuing a
> REGISTER for that logical UA from the pickup point.
> 
> Note that I'm sure there are far more elegant and sophisticated
> ways of doing these things within SIP...especially once one has a
> rich interface.  I would think that these sort of mappings
> only really need to be applied in dumb 'phone environments.
> 
> Cheers,
> 
>  - Jo.
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


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


From sip-admin@lists.bell-labs.com  Sat Jul 29 22:35: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 ESMTP id WAA28922
	for ; Sat, 29 Jul 2000 22:35:54 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 92D2E4436F; Sat, 29 Jul 2000 22:35:24 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bfgbhome.inetint.com (tnt-dal-42-246.dallas.net [209.44.42.246])
	by lists.bell-labs.com (Postfix) with ESMTP id 3E0A744336
	for ; Sat, 29 Jul 2000 22:35:19 -0400 (EDT)
Received: (from brian@localhost)
	by bfgbhome.inetint.com (8.9.3/8.9.3) id VAA19044;
	Sat, 29 Jul 2000 21:33:54 -0500
Date: Sat, 29 Jul 2000 21:33:54 -0500
From: "Brian F. G. Bidulock" 
To: Henning Schulzrinne 
Cc: Jo Hornsby , Hong Chen ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Call Park abd Call Pickup
Message-ID: <20000729213354.B17955@dallas.net>
Reply-To: bidulock@dallas.net
Mail-Followup-To: Henning Schulzrinne ,
	Jo Hornsby , Hong Chen ,
	sip@lists.bell-labs.com
References: <002f01bff877$2d3e5680$4e34c3c1@ubiquity.co.uk> <39838E75.5D4DB3FB@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <39838E75.5D4DB3FB@cs.columbia.edu>; from schulzrinne@cs.columbia.edu on Sat, Jul 29, 2000 at 10:09:57PM -0400
Organization: Brian F. G. Bidulock, P. Eng.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Henning,

If I recall correctly the purpose of Call Park and Call Pickup
was to "replicate a feature" of keysets (those ones with the
line 1, line 2 lit pushbuttons): that is, the ability to place a
call on hold and pick it up on another set, or place a call on
hold and holler across the room to someone on the phone with
another set (or buzz their Intercom line).  When we got those
Digital Centrex kind of phones, Call Park and Call Pickup tried
to replace these features: people who liked keysets would just
not purchase anything else otherwise.

With these features, we could park a call against someone's
number and when they hung up the phone it would ring through.
If it wasn't answered for some time, it would come back to the
"parker".  This was intuitively similar to placing the call on
hold an buzzing a person's intercom number.

Call pickup was so that one could place a call on hold and then
pick it up from another line by dialing feature code.  This was
helpful for moving around the office when a person was used to
keysets where one could place the call on line 3 on hold and
then just pickup another set and punch line 3.

Even though the features are provided on modern Digital Centrex
and PABX's, I don't know of many people that even use them: they
are too complicated and were only really intuitive if you had
been working with keysets for a long time.  You have to remember
that we didn't have voice mail, call waiting, or mobile (even
cordless) phones, which are far more popular today.  These
features had more to do with physically moving around the office
or running calls for a group of people with a single group
secretary.

The need that went with these features have been satisfied by other
means and are largely deprecated.  Far more sophisticated capabilities
has been provided with modern call centre approaches.

Henning Schulzrinne wrote:                (Sat, 29 Jul 2000 22:09:57)
> I think this may be a feature where we should ask "what do we want to
> accomplish from a user perspective", not "how do we replicate a
> feature called Call Park/Pickup". In particular, is this used for some
> unknown party to pick up, after the clerk hollers into the store PA
> system "whoever is in the adult diaper aisle, call on line 1?". If you
> know who you're addressing, with personal mobility, you can just
> transfer or redirect the call, without the intermediate parking.

-- 
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  Sat Jul 29 23:05:30 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02479
	for ; Sat, 29 Jul 2000 23:05:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D5F5F443C1; Sat, 29 Jul 2000 23:04:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 0113244336
	for ; Sat, 29 Jul 2000 23:04:48 -0400 (EDT)
Received: from dynamicsoft.com (1Cust154.tnt1.freehold.nj.da.uu.net [63.17.113.154])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA08292;
	Sat, 29 Jul 2000 23:02:29 -0400 (EDT)
Message-ID: <39839B70.4D5B4845@dynamicsoft.com>
Date: Sat, 29 Jul 2000 23:05:20 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rohan Mahy 
Cc: Jo Hornsby , Hong Chen ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Call Park abd Call Pickup
References: <39807F7B.868F8E02@cisco.com> <4.2.0.58.20000728102756.01bdb580@lint.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Rohan Mahy wrote:
> 
> Hi,
> 
> I think Pickup was well described in a previous thread.  If you wanted to
> do traditional Park things, I can think of 4 variations (with or without
> music, and with or without Revert)
> 
> I think I am suggesting essentially the same thing as Jo did.  You can read
> both and see if either make sense to you.
> 
> A and B have an existing session.
> 
> B sends a REFER to A, which redirects their session to
> 
>          
> 
> the forwarding logic for "so-queue-me"  would return a 182 call queued.  If
> desired, music/announcements could be played using 183 with Session: media.
> To retrieve the call just REGISTER "park-12" with a short expires timer.

How would B know which park address to use? The park address has to be
unique, and also has to
be something the person picking up would know to use. My suggestion -
instead of "12", you
would use the URL or address of the host which performed the park:



This way, if I want to pick up a call parked by B, I know I would have
to try to register the address above. You could then define pickup
groups by authenticating REGISTER, and only allowing people to register
for park-foo if they are in a group allowed to pickup calls parked by
foo.

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Sun Jul 30 01:33:42 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10036
	for ; Sun, 30 Jul 2000 01:33:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D5A2443B8; Sun, 30 Jul 2000 01:33:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1])
	by lists.bell-labs.com (Postfix) with ESMTP id C760F44336
	for ; Sun, 30 Jul 2000 01:32:57 -0400 (EDT)
Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135])
	by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id IAA04047
	for ; Sun, 30 Jul 2000 08:34:40 +0200 (IST)
From: Joshua_Fox@vocaltec.com
To: sip@lists.bell-labs.com
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: 
Date: Sun, 30 Jul 2000 08:32:21 +0200
X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 07/30/2000 08:32:21 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [SIP] non-audio/video  with SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

As a newcomer to SIP, I'm wondering about possible applications other than
audio/video. Has SIP been used to initiate other forms of human-to-human
interactive sessions, such as application sharing or collaborative
web-surfing?

The mailing list archives suggest that telephony is the primary application
of SIP, but the SIP protocol specifications impose few constraints on the
mode of communication.

Joshua Fox
Surf and Call Network Services
VocalTec Communications Limited



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


From sip-admin@lists.bell-labs.com  Sun Jul 30 10:01:23 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21761
	for ; Sun, 30 Jul 2000 10:01:23 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 947004434E; Sun, 30 Jul 2000 10:00:54 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail-in.audiocodes.com (unknown [192.115.62.60])
	by lists.bell-labs.com (Postfix) with ESMTP id C159644336
	for ; Sun, 30 Jul 2000 10:00:47 -0400 (EDT)
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21)
	id ; Sun, 30 Jul 2000 16:54:13 +0200
Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB248FB10@MAIL-IN>
From: Michel Eilat 
To: "'sip@lists.bell-labs.com'" 
Date: Sun, 30 Jul 2000 16:54:07 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Subject: [SIP] SIP Parser
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Hi folks,

Can someone recommend a good lexical software package (parser tool) to parse
SIP messages.

Thanks

Michel Eilat

Audiocodes LTD
4 Hahoresh St,
P.O.Box 14 Yehud 56470
Israel

Direct:      +972-3-5394160
Fax:         +972-3-5394040
Email:      michel.eilat@audiocodes.com
Web Site: http://www.audiocodes.com




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


From sip-admin@lists.bell-labs.com  Sun Jul 30 10:45:53 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05415
	for ; Sun, 30 Jul 2000 10:45:52 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 143DB4435F; Sun, 30 Jul 2000 10:45:24 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 7277744336
	for ; Sun, 30 Jul 2000 10:45:21 -0400 (EDT)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id JAA04616;
	Sun, 30 Jul 2000 09:45:19 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id JAA22695;
	Sun, 30 Jul 2000 09:45:19 -0500 (CDT)
Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA05107; Sun, 30 Jul 2000 09:45:18 -0500 (CDT)
From: Sean Olson 
Received: (from eussean@localhost)
	by b04a45.exu.ericsson.se (8.9.1/8.9.1) id JAA16474;
	Sun, 30 Jul 2000 09:45:17 -0500 (CDT)
Date: Sun, 30 Jul 2000 09:45:17 -0500 (CDT)
Message-Id: <200007301445.JAA16474@b04a45.exu.ericsson.se>
To: michel.eilat@audiocodes.com
Subject: Re: [SIP] SIP Parser
Cc: sip@lists.bell-labs.com
X-Sun-Charset: US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

 
> Hi folks,
> 
> Can someone recommend a good lexical software package (parser tool) to parse
> SIP messages.
> 
> Thanks
> 
> Michel Eilat

If you want to take this route, I would recommend

Flex - http://www.gnu.org/software/flex/flex.html
for lexical analysis

and

Bison - http://www.gnu.org/software/bison/bison.html
for parsing

Also see the SIP grammar at:
http://www.cs.columbia.edu/~hgs/sip/SIPgrammar.html

P.S.
Hopefully no one will start another "dialogue" on using a tool
versus hand-crafting a parser :)

--
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 Jul 30 11:01:54 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10151
	for ; Sun, 30 Jul 2000 11:01:53 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F28F144365; Sun, 30 Jul 2000 11:01:25 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from roma.axis.se (roma.axis.se [193.13.178.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 2D2B844336
	for ; Sun, 30 Jul 2000 11:01:22 -0400 (EDT)
Received: from klatt.axis.se (klatt.axis.se [193.13.178.133])
	by roma.axis.se (8.9.3/8.9.3) with ESMTP id RAA06530;
	Sun, 30 Jul 2000 17:00:43 +0200 (MEST)
Received: by klatt.axis.se with Internet Mail Service (5.5.2650.21)
	id ; Sun, 30 Jul 2000 17:00:22 +0200
Message-ID: <151F3D2AE9F0D3119E480004ACB8EA37018690C9@cluster01.axis.se>
From: Peter Kjellerstedt 
To: "'Sean Olson'" , michel.eilat@audiocodes.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP Parser
Date: Sun, 30 Jul 2000 16:59:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

> -----Original Message-----
> From: Sean Olson [mailto:eussean@exu.ericsson.se]
> Sent: 30 July 2000 16:45
> To: michel.eilat@audiocodes.com
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] SIP Parser
> 
> > Hi folks,
> > 
> > Can someone recommend a good lexical software package 
> > (parser tool) to parse SIP messages.
> > 
> > Thanks
> > 
> > Michel Eilat
> 
> If you want to take this route, I would recommend
> 
> Flex - http://www.gnu.org/software/flex/flex.html
> for lexical analysis

And be aware that it is anything but easy to create the flex
rules to cover the entire SIP grammar, though possible...

> and
> 
> Bison - http://www.gnu.org/software/bison/bison.html
> for parsing

And I would like to recommend Lemon (not nearly as known as Bison)
for parsing. It has a nice feature that it handles destruction
of tokens that are not used (especially useful when you get a
syntax error), which makes it much easier to avoid memory leaks...
Lemon can be found at: http://www.hwaci.com/sw/lemon/
At least my parser was greatly improved when I switched to Lemon 
(from Bison ;)

> Also see the SIP grammar at:
> http://www.cs.columbia.edu/~hgs/sip/SIPgrammar.html

Which is becoming rather outdated (compared to the bis draft...)

> P.S.
> Hopefully no one will start another "dialogue" on using a tool
> versus hand-crafting a parser :)
> 
> --
> Sean Olson 

//Peter


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


From sip-admin@lists.bell-labs.com  Sun Jul 30 14: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 ESMTP id OAA09372
	for ; Sun, 30 Jul 2000 14:33:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 197EA44351; Sun, 30 Jul 2000 14:33:38 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 7AD0F44336
	for ; Sun, 30 Jul 2000 14:33:35 -0400 (EDT)
Received: from provin-pc (provin-pc [192.4.8.117])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with SMTP id e6UIXYR18798
	for ; Sun, 30 Jul 2000 14:33:34 -0400 (EDT)
From: "Provin Gurung" 
To: 
Date: Sun, 30 Jul 2000 14:33:34 -0400
Message-ID: <010401bffa54$ab5fea90$750804c0@provin-pc.research.telcordia.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0105_01BFFA33.244E4A90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
X-MS-TNEF-Correlator: 00000000B9946541A605D411A9F500C04F6AF01084662300
Subject: [SIP] Not adding To tag in the re-invite final Response.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_0105_01BFFA33.244E4A90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This is on reference to the Appendix G. Changes to be made, section.

It state the following:

"Bug: A INVITEs B through a proxy, B responds to A with a tag in the To
field. Later, A sends a  re-INVITE to B, with a tag in the To field, through
the proxy. This request is malformed, so the proxy returns a 400 error.
Normally, a proxy will insert a tag into the To field of a 400 response. But
here, it cannot, since a tag is already present in the request. Thus, the
rule should be that if a request arrives with a tag, the entity sending a
response MUST NOT insert an additional tag, even if it a different entity
than the one that created the tag in the first place."

However I am worried about the ACK. Normally a proxy would generate an ACK
for the 4xx response that it received. Now if the proxy also proxies the
final response upstream without changing any tag information in the To
field, how would it identify that the ACK that might come back from the
upstream proxy/UA is destined for the proxy and not to be proxied
downstream.

Or should in case of re-Invites the Proxy should not send ACK's for non 2xx
final responses?

Thanks,

Proveen

------=_NextPart_000_0105_01BFFA33.244E4A90
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IiISAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHBwAeAA4AIQAAAAAAKwEB
A5AGAFwIAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAMwAAAE5vdCBhZGRpbmcgVG8gdGFnIGluIHRoZSByZS1pbnZpdGUgZmluYWwgUmVzcG9uc2Uu
AAACAXEAAQAAABYAAAABv/pUpKe22rz0W/QR1KoEAMBPavAQAAACAR0MAQAAACQAAABTTVRQOlBH
VVJVTkdAUkVTRUFSQ0guVEVMQ09SRElBLkNPTQALAAEOAAAAAEAABg4A1pGWVPq/AQIBCg4BAAAA
GAAAAAAAAAC5lGVBpgXUEan1AMBPavAQwoAAAAsAHw4BAAAAAwAGEHFMjMEDAAcQlAMAAB4ACBAB
AAAAZQAAAFRISVNJU09OUkVGRVJFTkNFVE9USEVBUFBFTkRJWEdDSEFOR0VTVE9CRU1BREUsU0VD
VElPTklUU1RBVEVUSEVGT0xMT1dJTkc6IkJVRzpBSU5WSVRFU0JUSFJPVUdIQVBST1gAAAAAAgEJ
EAEAAACgAwAAnAMAAIUFAABMWkZ1u3+zcwMACgByY3BnMTI1FjIA+Atgbg4QMDMznQH3IAKkA+MC
AGNoCsDgc2V0MCAHEwKDAFD/BFUQ2QhVB7ICgw5QA1UHY5YtCAMCgH0KgXVjAFDRCwN1bG4CIGUL
phTgWmgEACAXoQIgIAlwZoMEkAnwY2UgdG8YwCJoGLBBcHAJ8GRp8HggRy4TUBEADyAHkZ0Y0WIY
sADAAQAsIBEw6GN0aQIgLgqiCoAK49UKgEkFQHMBkHQYsRkR3QIQbAkAA/APIDobxB4IBwswEhIL
8DIgIkJ1Ax3gEXAgSU5WSVQ6RQQgQhjxA2AfwGggyGEgcANgeHkbICCg6Qlwc3ACIGQaYyAAA/B3
GQAhMQGQZxfAA6AZAlSlGOBmCJBsZBngTBzhfnIbICAAETAiQiFAGCEt+yAkGMJCGyAi3yPnGyAg
xt8ZAiFjGeAXgwlwcQpQHMBrF8IAwGwCEHIHgChBc3cY5CFjGCF0CHAGMSFANK4wEWAEkANgchng
Tirh/QdAbCGhIUUmoR2AI3ERMN8AICb3GNUj9hfwZiyVIfT/ETAZ4B+wBUAZEAlwGyAmwOwgYwBw
FrB0GyELgBih+ycFJWFsCXAa8CwAIWAHkJ8J8CpRI5Qp9SmCdXMoUuc1kRaQGLBzaAhgMKEasX8Z
ABzgF8Aw4in2CsAFEHb/B5EmuDaENQEmwCwAJSIdwUc4QzGEBdBVU1QHsE//PEAu5gOgGvAZkBty
B0A51P5lOTADoDghMqEhQBmQASD/GGIFQDp1N9EjlBbBN8QFAP80cBzwMLAZAicpJCARIAVAcwtR
GKAuIh5rDlAb00jXHaA+QQXASSEwbSagBbA/CIEwsAGgCGAFQBkDQ0vfLVguCDdTGkAW0HIc4gOR
z0axHVEFwBkCNHgZsDuH/zfUBUAJcBigOSEkYS1wB+D/OCEriAdAK1EhYgiQGmFCg/M9sjuHdXAc
wDRhRXEmwe9GMhDxDyA7I25AASczKtJ/HOAbgSdfMjBL8UgUMqFpOwEAOoFmQANGVzfEbWmvIRAy
sQNwGLBiANBrHVDPA2EY8073IWMvVSAAF6F/AQAcwAuAQZFJdkyVGYAg7zMBGnVNRDCwZB2gAIBP
I/sbtRvETwXANzUjgTLQO+GzMNElsm52JsBNlVAr0+83NVnyJSJGoicEIElyFrHMIDJKAU4Mcz8e
CheA/QBwazZwHgpewTkwCfAbxAUVwQBlQAMAEBAAAAAAAwAREAAAAAALAAGACCAGAAAAAADAAAAA
AAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAA
AAAAwAAAAAAAAEYAAAAAUoUAAPATAAAeAAiACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQA
AAA4LjUACwAMgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAA2ACCAGAAAAAADAAAAAAAAA
RgAAAAABhQAAAAAAAAsAFoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAXgAggBgAAAAAA
wAAAAAAAAEYAAAAAEYUAAAAAAAADABmACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AKIAI
IAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeACmACCAGAAAAAADAAAAAAAAARgAA
AAA3hQAAAQAAAAEAAAAAAAAAHgAqgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAA
AAsAMoAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwA0gAsgBgAAAAAAwAAAAAAAAEYAAAAA
AIgAAAAAAAALADaACyAGAAAAAADAAAAAAAAARgAAAAAFiAAAAAAAAAIB+A8BAAAAEAAAALmUZUGm
BdQRqfUAwE9q8BACAfoPAQAAABAAAAC5lGVBpgXUEan1AMBPavAQAgH7DwEAAACGAAAAAAAAADih
uxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcV0lO
TlRcUHJvZmlsZXNccGd1cnVuZy4wMDBcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9v
a1xvdXRsb29rLnBzdAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMEI5OTQ2
NTQxQTYwNUQ0MTFBOUY1MDBDMDRGNkFGMDEwODQ2NjIzMDAAAAAARPk=

------=_NextPart_000_0105_01BFFA33.244E4A90--



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


From sip-admin@lists.bell-labs.com  Sun Jul 30 14:44:14 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12333
	for ; Sun, 30 Jul 2000 14:44:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3478344371; Sun, 30 Jul 2000 14:43:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 3DC6444368
	for ; Sun, 30 Jul 2000 14:43:36 -0400 (EDT)
Received: from provin-pc (provin-pc [192.4.8.117])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with SMTP id e6UIhZR19020
	for ; Sun, 30 Jul 2000 14:43:35 -0400 (EDT)
From: "Provin Gurung" 
To: 
Date: Sun, 30 Jul 2000 14:43:35 -0400
Message-ID: <010801bffa56$11784790$750804c0@provin-pc.research.telcordia.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0109_01BFFA34.8A66A790"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
X-MS-TNEF-Correlator: 00000000B9946541A605D411A9F500C04F6AF01004672300
Subject: [SIP] Via's in CANCEL
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_0109_01BFFA34.8A66A790
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I have a doubt about the Via fields in the CANCEL request. If a proxy issues
a CANCEL for any branch, the Via field is initialized to the proxy. This is
made clear by the following excerpt in the bisRfc.

Section 4.2.5
"....The Via header field is initialized to the proxy issuing the CANCEL
request. (Thus, responses to this CANCEL request only reach the issuing
proxy.)"

However what happens in the case when a proxy is proxying a CANCEL request
downstream. Should it also remove all the via fields from the upstream
proxies and initialize the Via with just its own address. Seems that should
be this way to me, since CANCEL being a hop by hop request, a proxy
receiving a CANCEL has already sent a 200 OK to its  upstream proxy/ua
before proxying the request downstream and besides the response for the
CANCEL coming from downstream server is not proxied upstream.

Proveen

------=_NextPart_000_0109_01BFFA34.8A66A790
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IiMSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHBwAeAA4AKgAAAAAANAEB
A5AGAGAHAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAEAAAAFZpYSdzIGluIENBTkNFTAACAXEAAQAAABYAAAABv/pV5x622rz8W/QR1KoEAMBPavAQ
AAACAR0MAQAAACQAAABTTVRQOlBHVVJVTkdAUkVTRUFSQ0guVEVMQ09SRElBLkNPTQALAAEOAAAA
AEAABg4ATG/YVfq/AQIBCg4BAAAAGAAAAAAAAAC5lGVBpgXUEan1AMBPavAQwoAAAAsAHw4BAAAA
AwAGECI1odUDAAcQwgIAAB4ACBABAAAAZQAAAElIQVZFQURPVUJUQUJPVVRUSEVWSUFGSUVMRFNJ
TlRIRUNBTkNFTFJFUVVFU1RJRkFQUk9YWUlTU1VFU0FDQU5DRUxGT1JBTllCUkFOQ0gsVEhFVklB
RklFTERJU0lOSVRJQUwAAAAAAgEJEAEAAADHAgAAwwIAAFwEAABMWkZ1YA9wgQMACgByY3BnMTI1
FjIA+Atgbg4QMDMz3QH3IAKkA2QHYy0IAwKDAwBQA9VIZWx2ZXQ9DeBhAoMOUAPUAgBjaGUKwHMS
sDAgBxMCgH0ZCoF1YwBQCwN1bG6FAiBlC6UyIEkgFAChEqAgYSBkCGBiBUCnAaAIYAVAdGgXAFYH
MOQgZgiQbGQEIAuAF/OAQ0FOQ0VMIAlwonEKUHN0LhagZhcR8nADYHh5GOAEEBoBFxGfGWUCEAXA
AHAa8GJyAHDdE/AsF/wbARjhaRLAB0DsaXoJgBfwbxfzGrMaQDxUaB3yBCAAwAEAIGN0bGUKwWIa
8BgCAhBshwkAA/APICBleGMEkKsFMRj1YgQAUhPgLgqiNwqECoAGYGMSwAIgIDSQLjIuNSNkIi4l
Yf8fwBcAEcEYMwKxFsAgsASB/x2PHp8bAyHCGAIl4hllJmJlGdcoH8B1cxzwCXBz/nACIBQwBCAe
4ydxKf8Z87ogAiBsGvAJcADQaBfz8yk2H1QpIiNoCzEjgxNDtwHQEmAhoGUSoAXAdxQA8wVAFABw
cAnwGNcS4BQw/zJxCfAaiRqkIcIbhy32F0AqdwCAdC7BbRpAU2jnCGAnQheBbHMe8AlwBGB3FvIh
gBfzdhhYA1IX83XecDb0GqMIkBthbidRJ7dnF/cD8BgAIGoroCJhdKcEIDbBFxBkZCvhczdRrQng
bSxhMpJzN4RiPHL5J3F3YSEBHvAHgBzwAJDfHMAZRz/gNWQ3gHAg4kJi3xnVHPAalglwIiBpOVA1
eusUABthbC7BZBrwFDACMOcXEQHQFGBPSx7SPbI6jPh5L3UXID/gHBEfNSl2/zY/OjA7oj/gAJAB
AD8CSbLvLAQcAxkpBaBtIcI6A0pZ/RQwcjJCJ3EV4AVAOyQnUPs6liNbUANgEqAJ8CNkFPECAFKw
AAMAEBAAAAAAAwAREAAAAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYA
AAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPATAAAe
AAiACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUACwAMgAggBgAAAAAAwAAAAAAA
AEYAAAAABoUAAAAAAAADAA2ACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAFoAIIAYAAAAA
AMAAAAAAAABGAAAAAA6FAAAAAAAAAwAXgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADABmA
CCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AKIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAAB
AAAAAQAAAAAAAAAeACmACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAqgAgg
BgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsAMoAIIAYAAAAAAMAAAAAAAABGAAAA
AIKFAAABAAAACwA0gAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALADaACyAGAAAAAADAAAAA
AAAARgAAAAAFiAAAAAAAAAIB+A8BAAAAEAAAALmUZUGmBdQRqfUAwE9q8BACAfoPAQAAABAAAAC5
lGVBpgXUEan1AMBPavAQAgH7DwEAAACGAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5E
TEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcV0lOTlRcUHJvZmlsZXNccGd1cnVuZy4wMDBc
QXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xvdXRsb29rLnBzdAAAAAMA/g8FAAAA
AwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMEI5OTQ2NTQxQTYwNUQ0MTFBOUY1MDBDMDRGNkFG
MDEwMDQ2NzIzMDAAAAAAG6U=

------=_NextPart_000_0109_01BFFA34.8A66A790--



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


From sip-admin@lists.bell-labs.com  Sun Jul 30 16:49:30 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19005
	for ; Sun, 30 Jul 2000 16:49:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4096744368; Sun, 30 Jul 2000 16:48:53 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from paris.packetizer.local (rdu25-24-067.nc.rr.com [24.25.24.67])
	by lists.bell-labs.com (Postfix) with ESMTP id 9788144336
	for ; Sun, 30 Jul 2000 16:48:49 -0400 (EDT)
Received: from berlin (berlin.packetizer.local [192.168.1.4])
	by paris.packetizer.local (8.9.3/8.9.3) with SMTP id QAA07757;
	Sun, 30 Jul 2000 16:48:53 -0400
Message-ID: <010101bffa67$92bf0170$0401a8c0@berlin>
From: "Paul E. Jones" 
To: , 
References: 
Subject: Re: [SIP] non-audio/video  with SIP
Date: Sun, 30 Jul 2000 16:48:52 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Joshua,

One should certainly be able to use SIP for other types of conferences.  I
don't see any reason why the SDP could not be used to specify such protocols
as T.120, for example.

One could have a media description like this:
  m=application 1503 tcp t120

Of course, there's a few other details that need to be addressed, such as
registration of values with IANA and more formally specifying the exact
procedure, but there is certainly no reason why SIP could not be used to
initiate sessions that use other conferencing protocols.

Paul

----- Original Message -----
From: 
To: 
Sent: Sunday, July 30, 2000 2:32 AM
Subject: [SIP] non-audio/video with SIP


> As a newcomer to SIP, I'm wondering about possible applications other than
> audio/video. Has SIP been used to initiate other forms of human-to-human
> interactive sessions, such as application sharing or collaborative
> web-surfing?
>
> The mailing list archives suggest that telephony is the primary
application
> of SIP, but the SIP protocol specifications impose few constraints on the
> mode of communication.
>
> Joshua Fox
> Surf and Call Network Services
> VocalTec Communications Limited
>
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Jul 31 01:20:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28870
	for ; Mon, 31 Jul 2000 01:20:12 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2FF7A4435B; Mon, 31 Jul 2000 01:19:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2])
	by lists.bell-labs.com (Postfix) with ESMTP id C27BD44336
	for ; Mon, 31 Jul 2000 01:18:58 -0400 (EDT)
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id KAA00006
	for ; Mon, 31 Jul 2000 10:49:23 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Mon, 31 Jul 2000 10:46:03 +0000 (IST)
Received: from pcg140 (pcg140.sasi.com [10.0.64.140])
	by sung17.sasi.com (8.9.3/8.9.3) with SMTP id KAA27533
	for ; Mon, 31 Jul 2000 10:41:40 +0530 (IST)
Message-ID: <002501bffaad$62b860c0$8c40000a@sasi.com>
From: "rafi" 
To: 
Date: Mon, 31 Jul 2000 10:38:37 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0022_01BFFADB.7C3E4220"
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] How SIP is used to determine access mecahnsim ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01BFFADB.7C3E4220
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Section 1.1 of  RFC2543 says,

" For example, SIP could be used to determine that=20
the party can be reached via H.323 [7], obtain  the=20
H.245 [8] gateway and user address and then use
 H.225.0 [9] to establish the call."
=20
=20
Few questions=20

 1.  How SIP  is  used to determine such thing ?

 2.  How gateway and user address are carried in SIP  message ?

 3.   What is the meaning of H.245 gateway ?


 A message flow diagram would be useful.


Regards
Rafi Assadi H.M.




------=_NextPart_000_0022_01BFFADB.7C3E4220
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Section 1.1 of  RFC2543 =
says,


 


" For example, SIP could be used to determine that 


the party can be reached via H.323 [7], =

obtain  the 


H.245 [8] gateway and user address and =
then=20
use


 H.225.0 [9] to establish the=20
call."
 
 


Few questions 


 


 1.  How SIP  is  used =
to determine=20
such thing ?


 


 2.  How gateway and user =
address are=20
carried in SIP  message ?


 


 3.   What is the =
meaning of H.245=20
gateway ?


 


 


 A message flow diagram would be=20
useful.



 


Regards


Rafi Assadi H.M.


 



 


------=_NextPart_000_0022_01BFFADB.7C3E4220--



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


From sip-admin@lists.bell-labs.com  Mon Jul 31 02:26:56 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02842
	for ; Mon, 31 Jul 2000 02:26:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4705E44353; Mon, 31 Jul 2000 02:26:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sasi.com (samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2])
	by lists.bell-labs.com (Postfix) with ESMTP id C5D2344336
	for ; Mon, 31 Jul 2000 02:26:24 -0400 (EDT)
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id LAA02390;
	Mon, 31 Jul 2000 11:56:54 +0530 (IST)
Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Mon, 31 Jul 2000 11:56:49 +0000 (IST)
Received: from pcg140 (pcg140.sasi.com [10.0.64.140])
	by sung17.sasi.com (8.9.3/8.9.3) with SMTP id LAA28254;
	Mon, 31 Jul 2000 11:18:21 +0530 (IST)
Message-ID: <004001bffab2$82708c80$8c40000a@sasi.com>
From: "rafi" 
To: "Deepak Pant" , 
References: <200007291947.OAA47492@charlie.cns.iit.edu>
Subject: Re: [SIP] Behaviour of the expires header
Date: Mon, 31 Jul 2000 11:15:18 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


----- O> Does every proxy that receives an INVITE request
> needs to process the expires header?

   RFC does not mandate the processing of Expire
   Header field received in INVITE message. What it
   says is  time duration mentioned in Expire Header filed
   can be used  as upper limit for the user to respond when 
   processed at the called party. When processed at proxy 
   it can be used to limit  the search operation. 


>If every proxy
> processes an INVITE request with the expires header,
> then at the expiry of the INVITE, every proxy will
> issue a 408 status.

  Assuming all proxies have  decided to use Expire  Headre 
field  then it is more likely that the first proxy times out first 
resulting in sending 408 response. Other proxies  which 
eventualy times out and send 408 response are simply 
collected by other proxies  and may be ignored in this perticular
case.  


  Now consider two prxoies  say proxy1 and proxy2 involved 
in the transaction. If proxy1 decided  to use Expiry  field and proxy 2 
decided not use Expire ( Whether such combination are allowed
are not is not clear but should be possible because action of one
 proxy should be independent of others)  field,  in this case if prxoy 1
times out then  response received from proxy 2 will be of no use.
Thus it looks if Expire header field  is  to be processed then 
every proxy should process or else no one should process it.
It looks mixture of above two leads to inefficient usage of
this field.


Any comments ?

Rafi Assadi H.M.
 riginal Message ----- 
From: Deepak Pant 
To: 
Sent: Sunday, July 30, 2000 1:17 AM
Subject: [SIP] Behaviour of the expires header


> Does every proxy that receives an INVITE request
> needs to process the expires header? If every proxy
> processes an INVITE request with the expires header,
> then at the expiry of the INVITE, every proxy will
> issue a 408 status.
> 
> -Deepak
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Jul 31 04: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 ESMTP id EAA13611
	for ; Mon, 31 Jul 2000 04:47:14 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F016944360; Mon, 31 Jul 2000 04:46:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 48E9844336
	for ; Mon, 31 Jul 2000 04:46:49 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6V8kmQ15213
	for ; Mon, 31 Jul 2000 10:46:48 +0200 (MEST)
Received: from SMTP ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1);
	 Mon, 31 Jul 2000 10:46:47 +0200
Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by 153.88.251.29
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 31 Jul 2000 08:46:47 0000 (GMT)
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id ; Mon, 31 Jul 2000 10:45:32 +0200
Message-ID: <56E7307B0850D411B1480008C75DD5EAB73BFE@enlrynt303.dsn.ericsson.se>
From: "Arnoud van Wijk (ETM)" 
To: "'Joshua_Fox@vocaltec.com'" ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] non-audio/video  with SIP
Date: Mon, 31 Jul 2000 10:44:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-OriginalArrivalTime: 31 Jul 2000 08:46:47.0640 (UTC) FILETIME=[DC9F5D80:01BFFACB]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

The potential of SIP is that you can use it for anything that requires 2 or more parties/groups to contact each other.
IP telephony is indeed mostly worked on, but everything can be used with SIP.
For example Instant messaging, like ICQ. Or starting multiplay gaming sessions like Quake. Sending faxes over the internet can also be used with SIP to start the session.
SIP is also useful for mobility, to see where you are actually and what terminal/mobile phone/computer etc you are currently on. (via redirect servers/proxies).


I hope that this helps.


Arnoud van Wijk
_______________________________________________________________
ERICSSON TELECOMMUNICATIE BV
Arnoud van Wijk
Research & Development
ETM/BL/RE
Fax: +31-161 247569
_______________________________________________________________



-----Original Message-----
From: Joshua_Fox@vocaltec.com [mailto:Joshua_Fox@vocaltec.com]
Sent: Sunday, July 30, 2000 8:32 AM
To: sip@lists.bell-labs.com
Subject: [SIP] non-audio/video with SIP


As a newcomer to SIP, I'm wondering about possible applications other than
audio/video. Has SIP been used to initiate other forms of human-to-human
interactive sessions, such as application sharing or collaborative
web-surfing?

The mailing list archives suggest that telephony is the primary application
of SIP, but the SIP protocol specifications impose few constraints on the
mode of communication.

Joshua Fox
Surf and Call Network Services
VocalTec Communications Limited





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


From sip-admin@lists.bell-labs.com  Mon Jul 31 05:57:23 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28591
	for ; Mon, 31 Jul 2000 05:57:23 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 251A74436A; Mon, 31 Jul 2000 05:57:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 97B5944336
	for ; Mon, 31 Jul 2000 05:56:56 -0400 (EDT)
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA10347; Mon, 31 Jul 2000 10:55:06 +0100 (BST)
From: "Jo Hornsby" 
To: 
Subject: Re: [SIP] Not adding To tag in the re-invite final Response.
Date: Mon, 31 Jul 2000 10:55:06 +0100
Message-ID: <000d01bffad5$67728640$4e34c3c1@ubiquity.co.uk>
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 8.5, Build 4.71.2377.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 8bit

> This is on reference to the Appendix G. Changes to be made, section.
>
> It state the following:
>
> "Bug: A INVITEs B through a proxy, B responds to A with a tag in the
> To field. Later, A sends a  re-INVITE to B, with a tag in the To
> field, through the proxy. This request is malformed, so the proxy
> returns a 400 error. Normally, a proxy will insert a tag into the
> To field of a 400 response. But here, it cannot, since a tag is
> already present in the request. Thus, the rule should be that if
> a request arrives with a tag, the entity sending a response MUST NOT
> insert an additional tag, even if it a different entity than the one
> that created the tag in the first place."

I think that this is a bug which has actually been fixed.  See
Section 6.44 (To) of the July 13 bis, which says the following:
    "Section 11 describes when the “tag” parameter MUST appear in
     subsequent requests. Note that if a request already contained
     a tag, this tag MUST be mirrored in the response; a new tag
     MUST NOT be inserted."

> However I am worried about the ACK. Normally a proxy would generate
> an ACK for the 4xx response that it received. Now if the proxy
> also proxies the final response upstream without changing any
> tag information in the To field, how would it identify that the ACK
> that might come back from the upstream proxy/UA is destined for the
> proxy and not to be proxied downstream.

With the new bis rules about UAs having to insert Contact headers,
the signallying route is always well-defined for re-INVITES (whether
Record-Route was used or not).  Given this fact, only in the most
bizarre of cases will a re-INVITE not result in either:
 a) a 2xx class response; or
 b) a non-2xx class response.

In the case of 2xx, the reliability is end-to-end, as usual.
And in the case of non-2xx, the reliability is hop-by-hop, as usual.
The stateful proxy knows if it sent a response and what class
it was, so it is easy for it to deduce if the ACK is for itself or
not.

We had a bit of a discussion about this last week; see the thread
entitled "ACK handling at Stateful Proxies".

> Or should in case of re-Invites the Proxy should not send ACK's for
> non 2xx final responses?

Nah.  Proxies typically treat INVITES and re-INVITES identically;
the potentially different behaviour is implied by the presence or
otherwise of a Route header.

HTH,


 - 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  Mon Jul 31 09:26:06 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05491
	for ; Mon, 31 Jul 2000 09:26:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1D45144363; Mon, 31 Jul 2000 09:25:39 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 096DC44336
	for ; Mon, 31 Jul 2000 09:25:37 -0400 (EDT)
Received: from cs.columbia.edu (wired-129-124.ietf.marconi.com [147.73.129.124])
	by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01018;
	Mon, 31 Jul 2000 09:29:09 -0400 (EDT)
Message-ID: <39858033.5704692A@cs.columbia.edu>
Date: Mon, 31 Jul 2000 09:33:39 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rafi 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] How SIP is used to determine access mecahnsim ?
References: <002501bffaad$62b860c0$8c40000a@sasi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

This section is probably best understood as a historical artifact. Given
that it either requires a whole lot more explanation (and it is not
clear whether it has more than academic interest), I suggest dropping
it. Clearly, any place in SIP where a URL can be put could contain an
H.323 URL once such a thing gets defined [apparently in progress], but
that doesn't require explicit mention.

> rafi wrote:
> 
> Section 1.1 of RFC2543 says,
> 
> " For example, SIP could be used to determine that
> the party can be reached via H.323 [7], obtain  the
> H.245 [8] gateway and user address and then use
>  H.225.0 [9] to establish the call."
> 
> 
> Few questions
> 
>  1.  How SIP  is used to determine such thing ?
> 
>  2.  How gateway and user address are carried in SIP  message ?
> 
>  3.   What is the meaning of H.245 gateway ?
> 
> 
>  A message flow diagram would be useful.
> 
> 
> Regards
> Rafi Assadi H.M.
> 
> 
>


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


From sip-admin@lists.bell-labs.com  Mon Jul 31 09:59:16 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09570
	for ; Mon, 31 Jul 2000 09:59:16 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A247A44374; Mon, 31 Jul 2000 09:58:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 7173D44336
	for ; Mon, 31 Jul 2000 09:58:39 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6VDwcQ09421
	for ; Mon, 31 Jul 2000 15:58:38 +0200 (MEST)
Received: from ericsson.fi (E0080C7FA22D6.lmf.ericsson.se [131.160.30.144])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA14911
	for ; Mon, 31 Jul 2000 16:58:37 +0300 (EET DST)
Message-ID: <398585C2.57126199@ericsson.fi>
Date: Mon, 31 Jul 2000 16:57:22 +0300
From: Hisham Khartabil 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
References: <397D4202.72EADA57@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] LDAP schema for SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Hi all,

I was wondering if there has been any work done on an LDAP schema for SIP.
If so, I would appreciate a pointer to some documentation.  If not, can
someone give me some implementation hits on what the DN would look like
(using the To: header?? ).  Also the attribute types used for storing the
contact sip-uri, and parameters such as action, q, etc.

Much appreciated
Hisham



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


From sip-admin@lists.bell-labs.com  Mon Jul 31 10:03:50 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10170
	for ; Mon, 31 Jul 2000 10:03:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D146744378; Mon, 31 Jul 2000 10:03:45 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4])
	by lists.bell-labs.com (Postfix) with ESMTP id C710144372
	for ; Mon, 31 Jul 2000 10:03:42 -0400 (EDT)
Received: from cs.columbia.edu (wired-129-124.ietf.marconi.com [147.73.129.124])
	by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01061;
	Mon, 31 Jul 2000 10:07:52 -0400 (EDT)
Message-ID: <39858946.686708B1@cs.columbia.edu>
Date: Mon, 31 Jul 2000 10:12:22 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Hisham Khartabil 
Cc: sip 
Subject: Re: [SIP] LDAP schema for SIP
References: <397D4202.72EADA57@dynamicsoft.com> <398585C2.57126199@ericsson.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

No work that I know of. However, this would presumably just be an
extension of the usual 'Internet person' scheme (unless you want to use
LDAP as the backend for a registrar that stores more dynamic
reachability information). In most cases, an existing schema, with the
email address also serving as a SIP address, will be a good first
approximation.

We use LDAP in our sipd server and simply key on the email address in
the LDAD db or display name for local users.

Hisham Khartabil wrote:
> 
> Hi all,
> 
> I was wondering if there has been any work done on an LDAP schema for SIP.
> If so, I would appreciate a pointer to some documentation.  If not, can
> someone give me some implementation hits on what the DN would look like
> (using the To: header?? ).  Also the attribute types used for storing the
> contact sip-uri, and parameters such as action, q, etc.
> 
> Much appreciated
> Hisham
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Jul 31 11:14:56 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18897
	for ; Mon, 31 Jul 2000 11:14:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1C9EC4437D; Mon, 31 Jul 2000 11:14:36 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from polaris.shore.net (polaris.shore.net [207.244.124.105])
	by lists.bell-labs.com (Postfix) with ESMTP id C4FB844336
	for ; Mon, 31 Jul 2000 11:13:18 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by polaris.shore.net with esmtp (Exim)
	for sip@lists.bell-labs.com
	id 13JHFa-0006rY-00; Mon, 31 Jul 2000 11:13:06 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id LAA24795
	for ; Mon, 31 Jul 2000 11:06:29 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000731072618.00d3f490@webhost.tactical-sw.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 31 Jul 2000 10:43:06 -0400
To: sip@lists.bell-labs.com
From: David Yon 
Subject: Re: [SIP] SIP, SDP, and TCP-based media transport
In-Reply-To: <4.3.2.7.2.20000726101843.00d4a220@hither.rfdsoftware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

         Wow, not a single reply or comment.  Is there no interest/opinion 
at all on this subject?  Have I raised this subject in an inappropriate 
forum?  Does this duplicate work in other places that I've missed?  Should 
I take silence for agreement or is disagreement so strong that folks can 
hardly bring themselves to speak? :-)

         Any comments or suggestions appreciated.

At 10:31 AM 7/26/00 -0400, David Yon wrote:
>Attached is an informal discussion of various approaches to solving the 
>SDP/TCP problem.  Any comments are welcome.  If there is general agreement 
>I'd be happy to collaborate on or submit a formal I-D.
>
>With FOGLAMPS under way, and T.38 Annex D already finalized, this problem 
>needs to be solved as soon as possible.  While this may be more of an SDP 
>issue than a SIP issue, this problem is directly relevant to SIP which is 
>why I've posted this here.  If anyone has suggestions for additional 
>and/or more appropriate forums please let me know.
>


David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net



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


From sip-admin@lists.bell-labs.com  Mon Jul 31 12:15:08 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03676
	for ; Mon, 31 Jul 2000 12:15:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 746F144387; Mon, 31 Jul 2000 12:14:30 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id F152C4437E
	for ; Mon, 31 Jul 2000 12:14:26 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA03989;
	Mon, 31 Jul 2000 12:15:30 -0400 (EDT)
Message-ID: <3985A5B9.AF8AD11B@dynamicsoft.com>
Date: Mon, 31 Jul 2000 12:13:45 -0400
From: Igor Slepchin 
Organization: dynamicsoft Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Provin Gurung 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Via's in CANCEL
References: <010801bffa56$11784790$750804c0@provin-pc.research.telcordia.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Provin Gurung wrote:
> However what happens in the case when a proxy is proxying a CANCEL request
> downstream. 

The problem is with the meaning you put into "proxying a CANCEL
request". As you noted, CANCELs are hop-by-hop and are regenerated by
each proxy, hence, the Via of outgoing CANCELs is naturally initialized
to the address of the proxy sending the CANCEL. 

The only exception to this rule are stateless proxies. But for them,
CANCEL is no different from all other requests they are proxying. Note
that stateless proxies never generate responses.

---
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  Mon Jul 31 12:50:38 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09059
	for ; Mon, 31 Jul 2000 12:50:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B0B1D44382; Mon, 31 Jul 2000 12:50:26 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from jodie.lucid (unknown [212.25.93.158])
	by lists.bell-labs.com (Postfix) with SMTP id 1EA674437E
	for ; Mon, 31 Jul 2000 12:50:18 -0400 (EDT)
Received: (qmail 18896 invoked by uid 1002); 31 Jul 2000 16:45:16 -0000
From: Dvir Oren 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 31 Jul 2000 19:45:13 +0300 (IDT)
To: SIP 
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14725.44127.403193.648226@jodie.lucid>
Subject: [SIP] Proxy initiating a BYE
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

How can I have my proxy initiate a BYE?  Assuming this is after the
call has been started.  There are many difficulties here.  First of
all, it needs to send BYE in two ways.  One way can be easy - simply
sending the BYE the same route that the latest ACK went.  However, how 
do I send a BYE on the reverse route?  The best thing I can come up
with is converting the Via entries to Route entries, and adding some
'user' parameter.

Is there any better way of doing this?  It looks very ugly at this
point.

-- 
Dvir Oren               
Lucid VON Ltd.     
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039


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


From sip-admin@lists.bell-labs.com  Mon Jul 31 14:00:48 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17985
	for ; Mon, 31 Jul 2000 14:00:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B9C3344393; Mon, 31 Jul 2000 14:00:42 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id AA91F4437E
	for ; Mon, 31 Jul 2000 14:00:38 -0400 (EDT)
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 NAA13768;
	Mon, 31 Jul 2000 13:00:37 -0500 (CDT)
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 NAA04320;
	Mon, 31 Jul 2000 13:00:36 -0500 (CDT)
Received: from eamrcnt740.exu.ericsson.se ([138.85.133.41]) by 138.85.133.38
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 31 Jul 2000 18:00:35 0000 (GMT)
Received: by eamrcnt740.exu.ericsson.se with Internet Mail Service (5.5.2651.58)
	id ; Mon, 31 Jul 2000 13:00:34 -0500
Message-ID: <1614EED23D61D311B4B1005004D5F6C001AAD5CE@eamlynt750.ena-east.ericsson.se>
From: "Anthony Toubassi (EUS)" 
To: "'David Yon'" 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP, SDP, and TCP-based media transport
Date: Mon, 31 Jul 2000 13:00:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

David,
I did not receive the attachment to your message.  This may also explain the
lack of response/comments.  I think there is an interest in solving the
SDP/TCP/SCTP? problem, so please resend the attachment for review.

Thanks,
Anthony 
 Ericsson, Inc.
 anthony.toubassi@ericsson.com

-----Original Message-----
From: David Yon [mailto:yon@dialout.net]
Sent: Monday, July 31, 2000 10:43 AM
To: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP, SDP, and TCP-based media transport


         Wow, not a single reply or comment.  Is there no interest/opinion 
at all on this subject?  Have I raised this subject in an inappropriate 
forum?  Does this duplicate work in other places that I've missed?  Should 
I take silence for agreement or is disagreement so strong that folks can 
hardly bring themselves to speak? :-)

         Any comments or suggestions appreciated.

At 10:31 AM 7/26/00 -0400, David Yon wrote:
>Attached is an informal discussion of various approaches to solving the 
>SDP/TCP problem.  Any comments are welcome.  If there is general agreement 
>I'd be happy to collaborate on or submit a formal I-D.
>
>With FOGLAMPS under way, and T.38 Annex D already finalized, this problem 
>needs to be solved as soon as possible.  While this may be more of an SDP 
>issue than a SIP issue, this problem is directly relevant to SIP which is 
>why I've posted this here.  If anyone has suggestions for additional 
>and/or more appropriate forums please let me know.
>


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



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


From sip-admin@lists.bell-labs.com  Mon Jul 31 14:28:18 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21158
	for ; Mon, 31 Jul 2000 14:28:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4A4E344362; Mon, 31 Jul 2000 14:28:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 974DF44345
	for ; Mon, 31 Jul 2000 14:28:11 -0400 (EDT)
Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA16270
	for ; Mon, 31 Jul 2000 11:28:25 -0700 (PDT)
Received: from cisco.com ([171.71.159.231])
	by driftwood.cisco.com (Mirapoint)
	with ESMTP id ABN01969;
	Mon, 31 Jul 2000 13:25:03 -0500 (CDT)
Message-ID: <3985C585.E54CB6FB@cisco.com>
Date: Mon, 31 Jul 2000 13:29:25 -0500
From: Hong Chen 
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] SIP Call Control Services
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

The draft-ietf-mmusic-sip-cc-01.txt "SIP Call Control Services" was
expired In Dec. 1999.
The draft-sip-cc-transfer-00.txt  "SIP Call Control  Transfer" defines a
new method "REFER"  for the Call transfer which is
different from the  "SIP Call Control Services".

But what are about the different conference services defined in the
"SIP Call Control Services"?

Shall we still use ALSO/Replaces/Requested-By?

Also there are some conflictions between  draft-sip-cc-transfer-00.txt
"SIP Call Control  Transfer" (REFER for transfer) and
draft-mark-sip-dmcs-00txt "Distributed Multipoint Conferences using SIP"
(Bye ALSO for transfer) and both of these drafts are
active, which we should follow?

Should the "SIP Call Control Services" be updated as new SIP extensions
accepted and be kept as a central reference for the
SIP services?

What is the direction about SIP service area?






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


From sip-admin@lists.bell-labs.com  Mon Jul 31 14:34:12 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21964
	for ; Mon, 31 Jul 2000 14:34:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D4D634439D; Mon, 31 Jul 2000 14:33:28 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mta4-svc.virgin.net (mta4-svc.virgin.net [194.168.54.145])
	by lists.bell-labs.com (Postfix) with ESMTP id 5CB2344399
	for ; Mon, 31 Jul 2000 14:33:25 -0400 (EDT)
Received: from pqm-cons.demon.co.uk ([62.252.40.197])
          by mta4-svc.virgin.net (InterMail vM.4.01.02.27 201-229-119-110)
          with SMTP
          id <20000731183337.YPMW20084.mta4-svc.virgin.net@pqm-cons.demon.co.uk>;
          Mon, 31 Jul 2000 19:33:37 +0100
Message-ID: <000b01bffb1d$c6bc0f20$c528fc3e@pqm-cons.demon.co.uk>
From: "Alex Hardisty" 
To: 
Cc: , 
Subject: Re: [SIP] rfc2543bis: table 4 comments
Date: Mon, 31 Jul 2000 19:31:41 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

H. Schulzrinne wrote:

>Created an m* category: SHOULD sent, but receivers need to be
prepared
>to receive a request without it. Does that work?

Like Jonathan, I tend to think that it should be "o" rather than "m".
Leave the text to say "should".

I'm a bit concerned about introducing a new status "m*" when there is
already an International Standard (ISO 9646) defining a relatively
well-known set of permitted status answers for protocol and profile
ICS proformas.

--
Alex Hardisty
PQM Consultants





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


From sip-admin@lists.bell-labs.com  Mon Jul 31 14:38:08 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22392
	for ; Mon, 31 Jul 2000 14:38:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9590844399; Mon, 31 Jul 2000 14:37:34 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 78CE044345
	for ; Mon, 31 Jul 2000 14:37:31 -0400 (EDT)
Received: from CINQUECENTO (wireless-132-104.ietf.marconi.com [147.73.132.104])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id OAA04995;
	Mon, 31 Jul 2000 14:39:03 -0400 (EDT)
From: "Robert Sparks" 
To: "Hong Chen" , 
Subject: RE: [SIP] SIP Call Control Services
Date: Mon, 31 Jul 2000 13:35:39 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <3985C585.E54CB6FB@cisco.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

draft-sip-cc-transfer-00 is the direction for transfer.

conferencing is an open work item. There are several people
(including the author of the dcms draft mentioned below getting
a start on it and we plan to see a draft on the subject in the
near future.

RjS

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Hong Chen
> Sent: Monday, July 31, 2000 1:29 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] SIP Call Control Services
> 
> 
> The draft-ietf-mmusic-sip-cc-01.txt "SIP Call Control Services" was
> expired In Dec. 1999.
> The draft-sip-cc-transfer-00.txt  "SIP Call Control  Transfer" defines a
> new method "REFER"  for the Call transfer which is
> different from the  "SIP Call Control Services".
> 
> But what are about the different conference services defined in the
> "SIP Call Control Services"?
> 
> Shall we still use ALSO/Replaces/Requested-By?
> 
> Also there are some conflictions between  draft-sip-cc-transfer-00.txt
> "SIP Call Control  Transfer" (REFER for transfer) and
> draft-mark-sip-dmcs-00txt "Distributed Multipoint Conferences using SIP"
> (Bye ALSO for transfer) and both of these drafts are
> active, which we should follow?
> 
> Should the "SIP Call Control Services" be updated as new SIP extensions
> accepted and be kept as a central reference for the
> SIP services?
> 
> What is the direction about SIP service area?
> 
> 
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/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 Jul 31 14:40:17 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22647
	for ; Mon, 31 Jul 2000 14:40:16 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3B49D443BB; Mon, 31 Jul 2000 14:38:23 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from web2305.mail.yahoo.com (web2305.mail.yahoo.com [128.11.68.80])
	by lists.bell-labs.com (Postfix) with SMTP id C106F44345
	for ; Mon, 31 Jul 2000 14:38:19 -0400 (EDT)
Message-ID: <20000731183819.13719.qmail@web2305.mail.yahoo.com>
Received: from [147.73.134.86] by web2305.mail.yahoo.com; Mon, 31 Jul 2000 11:38:19 PDT
Date: Mon, 31 Jul 2000 11:38:19 -0700 (PDT)
From: Adam Roach 
To: aparna.vemuri@level3.com, jon.peterson@level3.com
Cc: adam.roach@ericsson.com, sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] SIP-T Draft Feedback
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Comments about draft-vemuri-sip-t-context-00.txt:

- On page 5, the point about "PSTN origination"
  should make mention that some ISUP modifications
  may occur to sync up with changes made by SIP
  proxies in the SIP network.

- In the call flows, you tend to map ACM messages
  to "183 Session Progress." In practice, ACMs
  typically have indication of "Subscriber
  free," which *should* map to "180 Ringing."
  Admittely, you don't have any ISUP parameters
  detailed in the call flows, but I think you
  shouldn't be using the exceptional cases to
  illustrate call flows.

- On page 10, there's a minor cut and paste error
  where the final BYE response is listed as BYE.

- Also in the call flow in page 10, note that
  the 200 response for BYE is used only for
  reliability; in ISUP, the RLC is used to
  indicate that a circuit is available for re-use.
  In most circumstances, it doesn't make sense
  to hold off the 200 response to the BYE
  until the RLC arrives.

- On page 14: I just want to bring your attention
  to the fact that much of the header mapping
  is already present in Gonzalo's and my draft.

- Also on page 14: it should be mentioned that
  encryption should be used for ISUP bodies.

- Section 6.2: It seems a bit odd to have a special
  purpose application server "fixing" the ISUP
  before it goes to the egress gateway. Since this
  gateway is already having to unpack the ISUP and
  (to some degree) understand it, it makes the
  most sense to perform that function in the MGC.

- On note 9: in Gonzalo's and My draft, we specify
  that any informationthat shouldn't be presented
  also shouldn't be mapped into SIP headers.
  I beleive this is a non-issue, as long as the
  ISUP bodies are encrypted.

Thanks for the good work!

- Adam Roach

(Mailing from Yahoo! from the IETF; prefered
address is typically adam.roach@ericsson.com)

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.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 Jul 31 14:42:28 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23017
	for ; Mon, 31 Jul 2000 14:42:27 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 96487443CD; Mon, 31 Jul 2000 14:38:59 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from polaris.shore.net (polaris.shore.net [207.244.124.105])
	by lists.bell-labs.com (Postfix) with ESMTP id C978644345
	for ; Mon, 31 Jul 2000 14:38:56 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by polaris.shore.net with esmtp (Exim)
	id 13JKSl-00041X-00; Mon, 31 Jul 2000 14:38:55 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id OAA24957;
	Mon, 31 Jul 2000 14:32:18 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000731143623.00d53890@webhost.tactical-sw.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 31 Jul 2000 14:39:22 -0400
To: "Anthony Toubassi (EUS)" 
From: David Yon 
Subject: RE: [SIP] SIP, SDP, and TCP-based media transport
Cc: sip@lists.bell-labs.com
In-Reply-To: <1614EED23D61D311B4B1005004D5F6C001AAD5CE@eamlynt750.ena-ea
 st.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

         The word "attached" was used a bit loosely, in fact the discussion 
was inlined ASCII.  Check the list archive to read it in full:

http://lists.bell-labs.com/pipermail/sip/2000q3/001768.html


At 01:00 PM 7/31/00 -0500, Anthony Toubassi (EUS) wrote:
>David,
>I did not receive the attachment to your message.  This may also explain the
>lack of response/comments.  I think there is an interest in solving the
>SDP/TCP/SCTP? problem, so please resend the attachment for review.
>
>Thanks,
>Anthony
>  Ericsson, Inc.
>  anthony.toubassi@ericsson.com


David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net



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


From sip-admin@lists.bell-labs.com  Mon Jul 31 14: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 ESMTP id OAA24405
	for ; Mon, 31 Jul 2000 14:54:31 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 08AD6443A3; Mon, 31 Jul 2000 14:54:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 2604744345
	for ; Mon, 31 Jul 2000 14:54:11 -0400 (EDT)
Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com [10.1.144.140])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id SAA14442;
	Mon, 31 Jul 2000 18:54:08 GMT
From: Jon.Peterson@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id MAA05609;
	Mon, 31 Jul 2000 12:43:33 -0600 (MDT)
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 31 Jul 2000 12:45:17 -0600
Message-ID: <87A245E94948D3118DE30008C716B01301523A7F@c0005v1idc1.oss.level3.com>
To: adamr@yahoo.com, Aparna.Vemuri@Level3.com
Cc: adam.roach@ericsson.com, sip@lists.bell-labs.com
Subject: RE: [SIP] SIP-T Draft Feedback
Date: Mon, 31 Jul 2000 12:43:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Are you here in Pittsburgh today, Adam? If so, let's get together and talk.

- Jon

-----Original Message-----
From: Adam Roach [mailto:adamr@yahoo.com]
Sent: Monday, July 31, 2000 2:38 PM
To: Vemuri, Aparna; Peterson, Jon
Cc: adam.roach@ericsson.com; sip@lists.bell-labs.com
Subject: [SIP] SIP-T Draft Feedback


Comments about draft-vemuri-sip-t-context-00.txt:

- On page 5, the point about "PSTN origination"
  should make mention that some ISUP modifications
  may occur to sync up with changes made by SIP
  proxies in the SIP network.

- In the call flows, you tend to map ACM messages
  to "183 Session Progress." In practice, ACMs
  typically have indication of "Subscriber
  free," which *should* map to "180 Ringing."
  Admittely, you don't have any ISUP parameters
  detailed in the call flows, but I think you
  shouldn't be using the exceptional cases to
  illustrate call flows.

- On page 10, there's a minor cut and paste error
  where the final BYE response is listed as BYE.

- Also in the call flow in page 10, note that
  the 200 response for BYE is used only for
  reliability; in ISUP, the RLC is used to
  indicate that a circuit is available for re-use.
  In most circumstances, it doesn't make sense
  to hold off the 200 response to the BYE
  until the RLC arrives.

- On page 14: I just want to bring your attention
  to the fact that much of the header mapping
  is already present in Gonzalo's and my draft.

- Also on page 14: it should be mentioned that
  encryption should be used for ISUP bodies.

- Section 6.2: It seems a bit odd to have a special
  purpose application server "fixing" the ISUP
  before it goes to the egress gateway. Since this
  gateway is already having to unpack the ISUP and
  (to some degree) understand it, it makes the
  most sense to perform that function in the MGC.

- On note 9: in Gonzalo's and My draft, we specify
  that any informationthat shouldn't be presented
  also shouldn't be mapped into SIP headers.
  I beleive this is a non-issue, as long as the
  ISUP bodies are encrypted.

Thanks for the good work!

- Adam Roach

(Mailing from Yahoo! from the IETF; prefered
address is typically adam.roach@ericsson.com)

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.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 Jul 31 16:01:10 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05837
	for ; Mon, 31 Jul 2000 16:01:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 13D9944362; Mon, 31 Jul 2000 16:00:52 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from web2305.mail.yahoo.com (web2305.mail.yahoo.com [128.11.68.80])
	by lists.bell-labs.com (Postfix) with SMTP id 4D66344345
	for ; Mon, 31 Jul 2000 16:00:48 -0400 (EDT)
Message-ID: <20000731200047.26972.qmail@web2305.mail.yahoo.com>
Received: from [147.73.129.190] by web2305.mail.yahoo.com; Mon, 31 Jul 2000 13:00:47 PDT
Date: Mon, 31 Jul 2000 13:00:47 -0700 (PDT)
From: Adam Roach 
To: sdonovan@dynamicsoft.com, jdrosen@dynamicsoft.com
Cc: adam.roach@ericsson.com, sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] draft-ietf-sip-session-timer-02.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

In section 3, the draft specifies that the
exiration for delta times are defined as
"[the] delta time plus the time at which the
header is observed in a response." Presumably,
you mean "final response," right? It should
probably be more explict; further, some note
should be made about "Session-Expires" in
1xx messages (if only to say that they are
disallowed).

In section 4, you specify that the lack of
require and session-timer headers in an
INVITE response imply that the UAC has no
further actions to take. This is somewhat
misleading. If, for example, the UAC sends
a "Supported: timer" header and a "Session-Expires"
header, but receives no timer indication in the
response, he still should be responsible for
initiating the periodic re-INVITEs for his
own use.

The combination of the recommendation that BYE
is sent ten seconds before the end of the session
expires and the recommendation that sessions
be refreshed at halfway through the expiration
period leads to the conlusion that refresh periods
must be larger than 20 seconds. If this is an
acceptable consequence (and I think it is), it
should probably be stated that these refresh
periods should be large enough to accomodate these
plus some slop. I suggest that the draft
recommend that timeouts are no smaller than
30 seconds.

The callflow that spans pages 11 and 12 shows
a circumstance where the calling UA requests
a timed session, and the SPS agrees to it.
You say that, after 120 seconds, the calling
UA decides not to refresh. However, since the
called UA understands the timer and agreed to
it (Require: timer), wouldn't he generally have
sent a BYE after 110 seconds? Am I missing
something?

Section 8.6 shows a callflow that has no basis
in any description of the draft. How, for
example, does the calling UA handle the
420 response? Yes, this is fairly straightforward,
but I really think it should be outlined in
the text of the draft.

Editorial comments:

- The first paragraph on page 4 includes the phrase
  "UAC and UAC" -- one of these should be "UAS."
- Table 1 and Table 4 should be labeled. (What
  happend to tables 2 and 3?)
- On page 8, the paragraph starting "If the final
  response..." contans the phrase "...and the proxy
  remembers that the proxy did not support session
  timer..." I imagine that the second "proxy" should
  be "client."
- Section 8.4, the first message from the SPS
  to the called UA should have a "Require" header
  in it (I think).

- Adam Roach
(Preferred address in non-IETF weeks:
adam.roach@ericsson.com)

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.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 Jul 31 17:03:13 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15622
	for ; Mon, 31 Jul 2000 17:03:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9C2DB4437B; Mon, 31 Jul 2000 17:03:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 9D6F54433B
	for ; Mon, 31 Jul 2000 17:03:07 -0400 (EDT)
Received: from dynamicsoft.com (ip116.honxr1.ras.tele.dk [195.249.119.116])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA06469;
	Mon, 31 Jul 2000 17:02:24 -0400 (EDT)
Message-ID: <3985E8C4.759583E8@dynamicsoft.com>
Date: Mon, 31 Jul 2000 16:59:48 -0400
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: David Yon 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP, SDP, and TCP-based media transport
References: <4.3.2.7.2.20000731072618.00d3f490@webhost.tactical-sw.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

David,

Here's a few comments.

You say in your intro that "A significant omission in SDP is a way to
specify TCP as the transport protocol."  Well, there is. There just
isn't a way for proxies to figure out a priori which party will connect
actively and which will accept the connection. This means (as I think
you also mention) that SIP with SDP *can* be used to set up TCP based
sessions only they have their own private arrangement about who gets to
be active/passive.

I agree with your views that having a separate TCP connection for each
direction is unsatisfying. You list some options for how to include in
the signaling an indication as to who will be active in the connection
setup. The one I like the best is the idea of using a port number of 0
to mean the other guy gets to be passive and choose a port number to
listen to and then tell the initiating party about it. I don't
understand your comments about flexibility on this one.

An alternative would be to use SDP attributes, e.g.

  m=chat 5678 TCP
  a=connection:passive

but it seems kind of pointless to use an attribute when there's a port
number begging to be overloaded ;-)

--
Anders Kristensen



David Yon wrote:
> 
>          Wow, not a single reply or comment.  Is there no interest/opinion
> at all on this subject?  Have I raised this subject in an inappropriate
> forum?  Does this duplicate work in other places that I've missed?  Should
> I take silence for agreement or is disagreement so strong that folks can
> hardly bring themselves to speak? :-)
> 
>          Any comments or suggestions appreciated.
> 
> At 10:31 AM 7/26/00 -0400, David Yon wrote:
> >Attached is an informal discussion of various approaches to solving the
> >SDP/TCP problem.  Any comments are welcome.  If there is general agreement
> >I'd be happy to collaborate on or submit a formal I-D.
> >
> >With FOGLAMPS under way, and T.38 Annex D already finalized, this problem
> >needs to be solved as soon as possible.  While this may be more of an SDP
> >issue than a SIP issue, this problem is directly relevant to SIP which is
> >why I've posted this here.  If anyone has suggestions for additional
> >and/or more appropriate forums please let me know.
> >
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> yon@dialout.net


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


From sip-admin@lists.bell-labs.com  Mon Jul 31 17:26:51 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18334
	for ; Mon, 31 Jul 2000 17:26:50 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 882EE443D3; Mon, 31 Jul 2000 17:26:16 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from polaris.shore.net (polaris.shore.net [207.244.124.105])
	by lists.bell-labs.com (Postfix) with ESMTP id F36094433B
	for ; Mon, 31 Jul 2000 17:26:12 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by polaris.shore.net with esmtp (Exim)
	id 13JN4U-00018R-00; Mon, 31 Jul 2000 17:26:02 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id RAA25094;
	Mon, 31 Jul 2000 17:19:24 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000731170511.00d448e0@webhost.tactical-sw.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 31 Jul 2000 17:26:28 -0400
To: Anders Kristensen 
From: David Yon 
Subject: Re: [SIP] SIP, SDP, and TCP-based media transport
Cc: sip@lists.bell-labs.com
In-Reply-To: <3985E8C4.759583E8@dynamicsoft.com>
References: <4.3.2.7.2.20000731072618.00d3f490@webhost.tactical-sw.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

         Thanks for taking the time to read/comment!  More discussion below...

At 04:59 PM 7/31/00 -0400, Anders Kristensen wrote:
>David,
>
>Here's a few comments.
>
>You say in your intro that "A significant omission in SDP is a way to
>specify TCP as the transport protocol."  Well, there is. There just
>isn't a way for proxies to figure out a priori which party will connect
>actively and which will accept the connection. This means (as I think
>you also mention) that SIP with SDP *can* be used to set up TCP based
>sessions only they have their own private arrangement about who gets to
>be active/passive.

         Well yes, the "TCP" identifier was just recently added, at the 
impetus of T.38 Annex D if I'm not mistaken.  So you can indeed specify a 
TCP transport, but as you say, right now the connection direction is left 
out of the SDP.  It's my position that this doesn't scale, especially for 
SIP ALP's.  Much better that it be explicit.


>I agree with your views that having a separate TCP connection for each
>direction is unsatisfying. You list some options for how to include in
>the signaling an indication as to who will be active in the connection
>setup. The one I like the best is the idea of using a port number of 0
>to mean the other guy gets to be passive and choose a port number to
>listen to and then tell the initiating party about it. I don't
>understand your comments about flexibility on this one.

         The problem with port zero is that it forces a server to use 
dynamic port assignments.  There are many cases where you want a TCP server 
to be sitting listening on a single port for incoming connections (indeed, 
this is the norm for most TCP-based services).  Assuming this topology, how 
is the server able to correlate an incoming connection to the original SIP 
caller?  In normal SIP/SDP, both sides specify an Address/Port pair, 
forming a unique four-tuple which identifies the session.  If you force the 
client-side port to be zero, you lose a critical piece of information 
necessary for the client to determine which party just connected.

         For example, let's say you have a server at 10.2.3.4 listening on 
port 2392, and it just got two SIP calls back-to-back which specify that 
two different parties want to set up a session with that server.  The twist 
is that the two different parties are at the same IP address of 63.5.4.3 
(could be a shared server, could be a NAT with a SIP ALP).  So now you have 
two four-tuples outstanding:

Caller A:       { 63.5.4.3, 0 }, { 10.2.3.4, 2392 }
Caller B:       { 63.5.4.3, 0 }, { 10.2.3.4, 2392 }

         When the server at 10.2.3.4 gets a connection on port 2392 from 
63.5.4.3, is it Caller A or Caller B?  We don't know, and that's the 
problem I'm talking about.

>An alternative would be to use SDP attributes, e.g.
>
>   m=chat 5678 TCP
>   a=connection:passive
>
>but it seems kind of pointless to use an attribute when there's a port
>number begging to be overloaded ;-)

         My problem here is that it forces ALP's down into the attribute 
line to be able to determine the connection direction.  Having TCP/S and 
TCP/C (or equivalent) means that the "m=" line is all the ALP needs to inspect.


David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net



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


From sip-admin@lists.bell-labs.com  Mon Jul 31 18:46:26 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00004
	for ; Mon, 31 Jul 2000 18:46:26 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2B40C443E0; Mon, 31 Jul 2000 18:46:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from polaris.shore.net (polaris.shore.net [207.244.124.105])
	by lists.bell-labs.com (Postfix) with ESMTP id 07C364433B
	for ; Mon, 31 Jul 2000 18:46:05 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by polaris.shore.net with esmtp (Exim)
	id 13JOJw-0005kS-00; Mon, 31 Jul 2000 18:46:04 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id SAA25161;
	Mon, 31 Jul 2000 18:39:27 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000731184625.00d45b10@webhost.tactical-sw.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 31 Jul 2000 18:46:30 -0400
To: Anders Kristensen 
From: David Yon 
Subject: Re: [SIP] SIP, SDP, and TCP-based media transport
Cc: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

At 06:26 PM 7/31/00 -0400, you wrote:

>Does that mean I've been using "TCP" as the transport illegally for
>nearly two years now? Good grief.

I can't authoritatively say so, but that would be my impression.


>OK, so if I understand you right you want to allow a UAC to be the
>active part in setting up the TCP connection while at the same time
>specifying which local TCP port it will be using in an initial INVITE,
>but without actually connecting before receiving the 2xx specifying the
>host/port to connect to, right?  I believe not all programming
>environments (think Java) will actually allow allocating a local port
>without connecting, although it sounds like a reasonable thing to do.

Yes, that would be a concern.  A quick peek at the latest Java docs does 
seem to bear out your assertion.  I guess that perhaps the initiator could 
be allowed to specify port zero if it truly could not determine its port, 
and for some transports/topologies that would be acceptable.  A smart SIP 
ALP could then decide that it is going to either proxy the connection 
itself (or could find out from the NAT/firewall what port will be used on 
the WAN side) and rewrite the SDP appropriately.


>On the whole it doesn't sound like this is much of a problem in
>practice, but if it is my preference would be for using an SDP m= level
>attribute over TCP/C TCP/S transport specifiers. Looks better, IMHO.

I'm not hung up on the nomenclature, if something like this was legal:

m=image 5291 TCP ACTIVE lpr     (UA that connects)
m=image 515 TCP PASSIVE lpr     (UA that accepts)

...then that would be fine with me.  I just would prefer that there be a 
way to specify the two categories of "TCP" while preferably keeping it on 
the m= line.  It was my impression that the format of the m= line was 
fairly strict, and that inserting a new specifier after TCP wouldn't fly.


David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net



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


From sip-admin@lists.bell-labs.com  Mon Jul 31 19:16:21 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05472
	for ; Mon, 31 Jul 2000 19:16:20 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 516094439A; Mon, 31 Jul 2000 19:15:49 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8E1E94433B
	for ; Mon, 31 Jul 2000 19:15:45 -0400 (EDT)
Received: from CINQUECENTO (wired-128-223.ietf.marconi.com [147.73.128.223])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id TAA07526
	for ; Mon, 31 Jul 2000 19:17:20 -0400 (EDT)
From: "Robert Sparks" 
To: 
Date: Mon, 31 Jul 2000 18:14:01 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Subject: [SIP] SIP Presence and Instant Messaging prototype
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

Greetings all -

For those who've not been following IMPP closely, here's
a copy of an announcement we sent to that group's list
a couple of days ago. (The better documentation mentioned
is in place.) If you're interested, pull down the client
and check it out.

The link below will take you to a page that has references
to the pertainant IDs. 

Ben and I are in Pittsburg - send us mail or come find us
if you have questions.

Thanks!

RjS

-----------------------------------------------------------------------
Hi,

Robert Sparks (rsparks@dynamicsoft.com) and I (bcampbell@dynamicsoft.com)
developed a Presence and Instant Messaging _prototype_ based on the SIP
proposal. We are making the client available for download at
http://www.dynamicsoft.com/presence_reg.html . There are also some release
notes that will help you set things up. We expect to have some better
documentation up shortly. The client is written in Java, and requires a
Java2 runtime environment.

We have also exposed a server at sip:impp.dfw.dynamicsoft.com:5060 . The
server is also a _prototype_.

Again, please note that this is an engineering prototype, and does not
represent our ideas of how the user interface would work in a real IMPP
product. Also, the server is not monitored on weekends or evenings, and
Robert and I will be traveling to Pittsburgh over the weekend. If you find
it down, send us email and we will fix things when we can.

Thanks!

Ben Campbell
dynamicsoft



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


From sip-admin@lists.bell-labs.com  Mon Jul 31 19:24:41 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06435
	for ; Mon, 31 Jul 2000 19:24:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0355444383; Mon, 31 Jul 2000 18:27:41 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 128154433B
	for ; Mon, 31 Jul 2000 18:27:39 -0400 (EDT)
Received: from dynamicsoft.com (ip46.honxr1.ras.tele.dk [195.249.119.46])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA07248;
	Mon, 31 Jul 2000 18:29:12 -0400 (EDT)
Message-ID: <3985FD1C.D849D6CC@dynamicsoft.com>
Date: Mon, 31 Jul 2000 18:26:36 -0400
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: David Yon 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP, SDP, and TCP-based media transport
References: <4.3.2.7.2.20000731072618.00d3f490@webhost.tactical-sw.com> <4.3.2.7.2.20000731170511.00d448e0@webhost.tactical-sw.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit


David Yon wrote:
> 
>          Thanks for taking the time to read/comment!  More discussion below...
> 
> At 04:59 PM 7/31/00 -0400, Anders Kristensen wrote:
> >David,
> >
> >Here's a few comments.
> >
> >You say in your intro that "A significant omission in SDP is a way to
> >specify TCP as the transport protocol."  Well, there is. There just
> >isn't a way for proxies to figure out a priori which party will connect
> >actively and which will accept the connection. This means (as I think
> >you also mention) that SIP with SDP *can* be used to set up TCP based
> >sessions only they have their own private arrangement about who gets to
> >be active/passive.
> 
>          Well yes, the "TCP" identifier was just recently added, at the
> impetus of T.38 Annex D if I'm not mistaken.

Does that mean I've been using "TCP" as the transport illegally for
nearly two years now? Good grief.

  So you can indeed specify a
> TCP transport, but as you say, right now the connection direction is left
> out of the SDP.  It's my position that this doesn't scale, especially for
> SIP ALP's.  Much better that it be explicit.
> 
> >I agree with your views that having a separate TCP connection for each
> >direction is unsatisfying. You list some options for how to include in
> >the signaling an indication as to who will be active in the connection
> >setup. The one I like the best is the idea of using a port number of 0
> >to mean the other guy gets to be passive and choose a port number to
> >listen to and then tell the initiating party about it. I don't
> >understand your comments about flexibility on this one.
> 
>          The problem with port zero is that it forces a server to use
> dynamic port assignments.  There are many cases where you want a TCP server
> to be sitting listening on a single port for incoming connections (indeed,
> this is the norm for most TCP-based services).  Assuming this topology, how
> is the server able to correlate an incoming connection to the original SIP
> caller?  In normal SIP/SDP, both sides specify an Address/Port pair,
> forming a unique four-tuple which identifies the session.  If you force the
> client-side port to be zero, you lose a critical piece of information
> necessary for the client to determine which party just connected.

OK, so if I understand you right you want to allow a UAC to be the
active part in setting up the TCP connection while at the same time
specifying which local TCP port it will be using in an initial INVITE,
but without actually connecting before receiving the 2xx specifying the
host/port to connect to, right?  I believe not all programming
environments (think Java) will actually allow allocating a local port
without connecting, although it sounds like a reasonable thing to do.

On the whole it doesn't sound like this is much of a problem in
practice, but if it is my preference would be for using an SDP m= level
attribute over TCP/C TCP/S transport specifiers. Looks better, IMHO.

--
Anders Kristensen


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


From sip-admin@lists.bell-labs.com  Mon Jul 31 20:27:11 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14814
	for ; Mon, 31 Jul 2000 20:27:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8061A443AB; Mon, 31 Jul 2000 20:26:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchangesvr.nuera.com (unknown [204.216.240.124])
	by lists.bell-labs.com (Postfix) with ESMTP id 576B84433B
	for ; Mon, 31 Jul 2000 20:26:42 -0400 (EDT)
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id <3T7JFVGC>; Mon, 31 Jul 2000 17:27:43 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'David Yon'" ,
        Anders Kristensen 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP, SDP, and TCP-based media transport
Date: Mon, 31 Jul 2000 17:27:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

Just thought I'd interject:

>          The problem with port zero is that it forces a server to use 
> dynamic port assignments.  There are many cases where you 
> want a TCP server 
> to be sitting listening on a single port for incoming 
> connections (indeed, 
> this is the norm for most TCP-based services).  Assuming this 
> topology, how 
> is the server able to correlate an incoming connection to the 
> original SIP 
> caller?  In normal SIP/SDP, both sides specify an Address/Port pair, 
> forming a unique four-tuple which identifies the session.  If 
> you force the 
> client-side port to be zero, you lose a critical piece of information 
> necessary for the client to determine which party just connected.
> 
I was under the impression that for the UDP case each SDP body specifies
only the destination port and that UDP packets do NOT have to have to have
their source port equal to the opposing destination port!! This same
property should be reflected in any TCP model, should it not ?

Robert.


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


From sip-admin@lists.bell-labs.com  Mon Jul 31 21:17:56 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22620
	for ; Mon, 31 Jul 2000 21:17:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 271AB443DE; Mon, 31 Jul 2000 21:17:41 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from polaris.shore.net (polaris.shore.net [207.244.124.105])
	by lists.bell-labs.com (Postfix) with ESMTP id 44C364433B
	for ; Mon, 31 Jul 2000 21:17:37 -0400 (EDT)
Received: from (hither.rfdsoftware.com) [209.192.222.62] 
	by polaris.shore.net with esmtp (Exim)
	id 13JQga-0005B7-00; Mon, 31 Jul 2000 21:17:36 -0400
Received: from cx991414-a.dialout.net (cx991414-a.crans1.ri.home.com [24.0.249.47])
	by hither.rfdsoftware.com (8.9.2/8.9.2) with ESMTP id VAA25257;
	Mon, 31 Jul 2000 21:10:58 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000731211620.00d10400@webhost.tactical-sw.com>
X-Sender: dnyon@webhost.tactical-sw.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 31 Jul 2000 21:17:57 -0400
To: "Fairlie-Cuninghame, Robert" ,
        Anders Kristensen 
From: David Yon 
Subject: RE: [SIP] SIP, SDP, and TCP-based media transport
Cc: sip@lists.bell-labs.com
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

At 05:27 PM 7/31/00 -0700, Fairlie-Cuninghame, Robert wrote:
>Just thought I'd interject:
>
> >          The problem with port zero is that it forces a server to use
> > dynamic port assignments.  There are many cases where you
> > want a TCP server
> > to be sitting listening on a single port for incoming
> > connections (indeed,
> > this is the norm for most TCP-based services).  Assuming this
> > topology, how
> > is the server able to correlate an incoming connection to the
> > original SIP
> > caller?  In normal SIP/SDP, both sides specify an Address/Port pair,
> > forming a unique four-tuple which identifies the session.  If
> > you force the
> > client-side port to be zero, you lose a critical piece of information
> > necessary for the client to determine which party just connected.
> >
>I was under the impression that for the UDP case each SDP body specifies
>only the destination port and that UDP packets do NOT have to have to have
>their source port equal to the opposing destination port!! This same
>property should be reflected in any TCP model, should it not ?
>
>Robert.
>
>

         You are correct, but I did not mean to infer that both sides would 
specify the *same* Address/Port pair.  Certainly the addresses would be 
different, and it would only be coincidence if the port numbers were to be 
the same.


David Yon
Chief Technical Officer
Dialout.Net, Inc.
yon@dialout.net



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


From sip-admin@lists.bell-labs.com  Mon Jul 31 21:34:51 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26029
	for ; Mon, 31 Jul 2000 21:34:50 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6F8FE443E9; Mon, 31 Jul 2000 21:34:24 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id E32BE4433B
	for ; Mon, 31 Jul 2000 21:34:20 -0400 (EDT)
Received: from dynamicsoft.com (wired-128-198.ietf.marconi.com [147.73.128.198])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA07948;
	Mon, 31 Jul 2000 21:35:41 -0400 (EDT)
Message-ID: <39862A2A.878BBF63@dynamicsoft.com>
Date: Mon, 31 Jul 2000 21:38:50 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dvir Oren 
Cc: SIP 
Subject: Re: [SIP] Proxy initiating a BYE
References: <14725.44127.403193.648226@jodie.lucid>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit



Dvir Oren wrote:
> 
> How can I have my proxy initiate a BYE? 

They can't. Proxies never initiate requests on their own. Its the
defining characteristic of a proxy.

> Assuming this is after the
> call has been started.  There are many difficulties here.  First of
> all, it needs to send BYE in two ways.  One way can be easy - simply
> sending the BYE the same route that the latest ACK went.  However, how
> do I send a BYE on the reverse route?  The best thing I can come up
> with is converting the Via entries to Route entries, and adding some
> 'user' parameter.
> 
> Is there any better way of doing this?  It looks very ugly at this
> point.

Yes, don't do it with a proxy. If an entity in the middle of the network
is sending a BYE, it is not a proxy. It is likely some kind of
application server acting as a B2BUA. See the 3pcc draft for some ideas
on how this works.

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-3pcc-00.txt

-Jonathan R.

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


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


From sip-admin@lists.bell-labs.com  Mon Jul 31 22:24:21 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07645
	for ; Mon, 31 Jul 2000 22:24:20 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EEC324437C; Mon, 31 Jul 2000 22:24:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by lists.bell-labs.com (Postfix) with SMTP id 7AE2E4433B
	for ; Mon, 31 Jul 2000 22:23:55 -0400 (EDT)
Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 31 Jul 2000 19:14:47 -0700 (Pacific Daylight Time)
Received: from STAY.platinum.corp.microsoft.com ([172.30.236.91]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023);
	 Mon, 31 Jul 2000 19:23:38 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4415.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFFB5F.24F4E0DA"
Date: Mon, 31 Jul 2000 19:21:05 -0700
Message-ID: <078292D50C98D2118D090008C7E9C6A6018A812E@STAY.platinum.corp.microsoft.com>
Thread-Topic: Change in SIP URL syntax
Thread-Index: Ab/7Xz2t1FLEZpSzRsy5YDPQE5qJDA==
From: "Ajay Chitturi" 
To: 
X-OriginalArrivalTime: 01 Aug 2000 02:23:38.0706 (UTC) FILETIME=[80902B20:01BFFB5F]
Subject: [SIP] Change in SIP URL syntax
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFFB5F.24F4E0DA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I noticed the following change in the SIP URL syntax in the latest
version of 2543bis

	Added semicolon and question mark to the list of unreserved
characters for the user part of SIP URLs
	to handle tel: URLs properly.

Wouldn't the change make URL parsing ambiguous ?

For eg. the URL  could be parsed in two different ways :
(i) host is a and param is b=3Dc@d
(ii) user is a;b=3Dc and host is d

Am I missing something ?
Is there a simple way to parse URL's with this change ?

Thanks
Ajay.

------_=_NextPart_001_01BFFB5F.24F4E0DA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Change in SIP URL syntax





Hi,




I noticed the following change in the =
SIP URL syntax in the latest version of 2543bis




        Added semicolon and question mark to the list of unreserved =
characters for the user part of SIP URLs


        to handle tel: URLs properly.




Wouldn't the change make URL parsing =
ambiguous ?




For eg. the URL <sip:a;b=3Dc@d> =
could be parsed in two different ways :


(i) host is a and param is =
b=3Dc@d


(ii) user is a;b=3Dc and host is =
d




Am I missing something ?


Is there a simple way to parse URL's =
with this change ?




Thanks


Ajay.





------_=_NextPart_001_01BFFB5F.24F4E0DA--


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


From sip-admin@lists.bell-labs.com  Mon Jul 31 23:00:32 2000
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12633
	for ; Mon, 31 Jul 2000 23:00:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D6AD44393; Mon, 31 Jul 2000 22:59:51 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 159B64433B
	for ; Mon, 31 Jul 2000 22:59:48 -0400 (EDT)
Received: from postal.research.att.com (postal.research.att.com [135.207.23.30])
	by mail-blue.research.att.com (Postfix) with ESMTP id A1B024CE5B
	for ; Mon, 31 Jul 2000 22:59:47 -0400 (EDT)
Received: from research.att.com ([135.210.107.169])
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id WAA14802
	for ; Mon, 31 Jul 2000 22:59:44 -0400 (EDT)
Message-ID: <39863CCA.2C234420@research.att.com>
Date: Mon, 31 Jul 2000 22:58:18 -0400
From: "Gregory W. Bond" 
Organization: AT&T Labs - Research, Florham Park, NJ
X-Mailer: Mozilla 4.72 [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] IP Telecom Services Workshop 2000: Call for Participation
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List 
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit

[Please accept our apologies for multiple copies of this call.]

-------------  CALL FOR PARTICIPATION  ---------------

       IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000)

                    co-located with
             Fall 2000 Voice on the Net (VON)

                     organized by
                  AT&T Labs Research
                      pulver.com

         Cobb Galleria, Atlanta, Georgia, U.S.A
                  September 11, 2000

         http://www.research.att.com/conf/ipts2000/

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

IPTS 2000 is a new workshop dedicated to the important, emerging field of IP
Telecom Services research.

In contrast to the services available on the PSTN, a new world of telecom
services is possible on an IP-based infrastructure. This world presents new
challenges for service development, deployment and management. This one-day
workshop will serve as a forum for the dissemination of research relating to
these challenges.

We have put together an excellent technical program that includes 8 original
research papers, a plenary talk, and a round table discussion. We look forward
to the participation from you and your colleagues in the telecom industry and
the research community.

TECHNICAL PROGRAM

Plenary Talk - speaker to be announced

DFC as the basis for ECLIPSE, an IP communications software platform
Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal
Purdy, Chris Ramming, and Pamela Zave
AT&T Labs Research

Experimenting with PARLAY in a SIP Environment: Early Results
Stephane Desrochers, Roch H. Glitho, Kindy Sylla
Ericsson Research Canada

Approach For Services in Converged Networks
Sanjiv Kapur, Rakesh Vij
Hughes Software Systems

Unified Messaging using SIP and RTSP
Kundan Singh and Henning Schulzrinne
Columbia University

SPHINX: A Study in Convergent Telephony
Kumar V. Vemuri
Lucent Technologies

SPHINX: Advanced Scenarios for H.323-SIP Interoperation
Kumar V. Vemuri
Lucent Technologies

Where Should Services Reside in Internet Telephony Systems?
Xiaotao Wu and Henning Schulzrinne
Columbia University

A Transformation Approach for Service Creation in a Hybrid IP-IN Network
Cyril Carrez, Elie Najm, Alexandre Tauveron
Ecole Nationale Superieure des Telecom

Roundtable Discussion - topic to be announced


CONFERENCE VENUE AND RELATED EVENTS

IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop
will be co-located with Fall 2000 Voice on the Net (VON). Registration details
about Fall 2000 VON can be found at http://pulver.com.

IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and
pulver.com (http://pulver.com).


WORKSHOP CO-CHAIRS

Greg Bond, AT&T Labs Research
Eric Cheung, AT&T Labs Research

PROGRAM COMMITTEE

Mauricio Arango, Sun Microsystems Labs
Joanne Atlee, University of Waterloo
Ralph Blumenthal, Daewoo Telecom
Scott Hoffpauir, BroadSoft
Evan Magill, University of Strathclyde
Peter Mataga, dynamicsoft
Bernie Pagurek, Carleton University
Jonathan Rosenberg, dynamicsoft
Henning Schulzrinne, Columbia University
Greg Utas, Nortel Networks
Pamela Zave, AT&T Labs Research


FURTHER GENERAL INFORMATION

http://www.research.att.com/conf/ipts2000


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